Python 3.1 support
in [PgSql]
|
Prev: New VACUUM FULL
Next: Aggregate ORDER BY patch
From: "Joshua D. Drake" on 18 Nov 2009 12:21 On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: > Nathan Boley <npboley(a)gmail.com> writes: > > Also, I am a little skeptical about this patch. I am sorry if this has > > already been discussed, but would this mean that I need to choose > > whether pl/python is built against Python 2.* or Python 3.*? > > Yes. That's exactly what I was complaining about upthread. I'm not > a Python user, but from what I can gather of the 2-to-3 changes, > having to choose one at package build time is going to be a disaster. > Agreed. We really need to have a plpython and plpython3. Heck this would play nicely too because we support backward compatibility but also upward version differences. Joshua D. Drake > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 18 Nov 2009 12:28 "Joshua D. Drake" <jd(a)commandprompt.com> writes: > On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: >> Yes. That's exactly what I was complaining about upthread. I'm not >> a Python user, but from what I can gather of the 2-to-3 changes, >> having to choose one at package build time is going to be a disaster. > Agreed. We really need to have a plpython and plpython3. Peter was concerned about duplicative maintenance effort, but what I think this patch shows is that (at least for the near future) both could be built from a single source file. What we need is configure and makefile support to do that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 18 Nov 2009 12:48 On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote: > "Joshua D. Drake" <jd(a)commandprompt.com> writes: > > On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: > >> Yes. That's exactly what I was complaining about upthread. I'm not > >> a Python user, but from what I can gather of the 2-to-3 changes, > >> having to choose one at package build time is going to be a disaster. > > > Agreed. We really need to have a plpython and plpython3. > > Peter was concerned about duplicative maintenance effort, but what I > think this patch shows is that (at least for the near future) both > could be built from a single source file. What we need is configure > and makefile support to do that. Ahh, so we would have: --enable-plpython2=/usr/bin/python2 --enable-plpython3=/usr/bin/python3 ? That seems reasonable if we can run both. Although I wonder if longer term (2.x is going to be support a long time) we will end up with frustration within the single source file trying to keep things straight. Joshua D. Drake > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 18 Nov 2009 12:50 "Joshua D. Drake" <jd(a)commandprompt.com> writes: > On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote: >> Peter was concerned about duplicative maintenance effort, but what I >> think this patch shows is that (at least for the near future) both >> could be built from a single source file. > That seems reasonable if we can run both. Although I wonder if longer > term (2.x is going to be support a long time) we will end up with > frustration within the single source file trying to keep things > straight. Once it gets to the point where it's more trouble to keep them together than not, we can split the source. But judging from this patch, a single source file is the ticket for the moment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Nathan Boley on 18 Nov 2009 14:32
> Here's the patch to support Python >=3.1 with PL/Python. The > compatibility code is mostly in line with the usual 2->3 C porting > practice and is documented inline. 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. Also, how far back do we want to maintain 2.x compatibility? 2.0? 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? 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? 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. 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. 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. I'm sorry to snipe from the sidelines like this. If we didn't expect plpython to evolve then this patch seems like the correct approach, but there is clearly some desire to expand plpython and following this path seems like it will end in a much more painful split in the future or a necessary rewrite. If there is some consensus that this is the best approach, then I will do a more comprehensive review. -Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |