Re: Python 3.1 support

On ons, 2009-11-18 at 11:32 -0800, Nathan Boley wrote:
> I took a cursory look at this patch and, while the logic seems sound
> and roughly in line with the suggested python porting procedure, I'm
> not quite certain what this implies for potential future patches.
>
> For instance, if I wanted to write a type converter for bytea -> the
> python 3 byte type would the expectation be that I ensure that it
> works in Python 2? Or is an ifdef that ignores it in the case of
> Python 2 OK, and we can just put a note in the docs.

Note that this is already implemented. The main point of the patch is
to provide a small compatibility layer so that these kinds of issues are
practically nonexistent. The fact that you didn't notice might prove
that the patch does its job. ;-)

> Also, how far back do we want to maintain 2.x compatibility? 2.0?

We handle this on an ad hoc basis. We currently support Python 2.2 and
later, and this cutoff exists -- this is my interpretation of history --
because 2.2 introduced iterators and no one bothered(?) to put ifdefs
around the code in PL/Python that provides iterator support. Over the
years, we will probably drop support for other older Python versions,
but there is no process or plan for that. Right now, the support for
Python 2.2 is about three lines, so it's not a bother, but when someone
comes and implements a major feature that, say, requires Python 2.3, we
can probably drop 2.2. But when the major feature requires 2.6, we
probably don't want to drop 2.5 quite yet at this time. It's a judgment
call.

> If I
> wanted to submit a patch that makes use of the list sort method, do I
> need to ensure that it can either use the cmp arguments or a key
> argument?

Any patch one is likely to submit will be a C patch, not a Python patch.
But anyway, the "key" argument was introduced in Python 2.4, and so we'd
have to come to a decision in the community about whether Python 2.3
support is worth keeping versus the value of that new feature. See above.

But anyway, this problem has nothing to do with my patch; it has already
existed in the same form forever.

> What if I wanted to implement a set returning function that made use
> of an iterators next() method. Would I just put ifdefs around the code
> or a preprocessor definition that defines NEXT as next() for Python
> 2.x and __next__() for 3.x?

Again, you would likely submit a C patch, and the iterator API is the
same between 2.x and 3.x.

> I guess that my first impression is that Python broke compatibility
> for a reason, and that either plpython can't evolve, or it will
> quickly become impossible to maintain.

I think this is an exaggeration of reality. Python 3 removed deprecated
features. There is a perfectly good migration path that covers most
code: Switch to Python 2.6, switch to the new features, remove the old
features, switch to Python 3.x. This applies both on the Python and the
C level. They did not break compatibility with the intention of making
every module author out there reimplement their thing from scratch.
Otherwise Python 2.6 would make very little sense at all.

Take a look at an example closer to home: PostgreSQL breaks C API
compatibility in almost every major release. We do this to remove cruft
and support new features. The intent is not to make Slony and PostGIS
and all the other modules reimplement their product from scratch every
time. They put in a few ifdefs, sometimes they complain about it ;-),
and then the problem is solved.

> That being said, I mostly buy
> the maintenance arguments from the previous discussion, but if we want
> to have plpython and plpython3, a bunch of defines and ifdefs does not
> seem like the best way to do this.

These ifdefs were not my idea. They are in some cases directly and in
some cases in spirit from the Python 2.6 header files, so they are the
official way to do this.

> Would a better approach be to maintain compatibility layer? ie
> plython_compat.h/c
> plython2.c
> plython3.c
>
> Then patches that apply to a python3 can be applied to plython3.c and
> any changed function can be ripped out of plython_compat and moved
> into plpython2.

As I tried to explain above, we have always had a rolling feature model
of sorts, even across various Python 2.x versions. If you want to try
it out, you could take the current source and split it up into
plpython22.c, plpython23.c, etc. and see if that becomes useful.