Python 3.1 support
in [PgSql]
|
Prev: New VACUUM FULL
Next: Aggregate ORDER BY patch
From: Tom Lane on 12 Nov 2009 16:06 Peter Eisentraut <peter_e(a)gmx.net> writes: > 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. There was considerable debate earlier about whether we wanted to treat Python 3 as a separate PL so it could be available in parallel with plpython 2, because of the user-level coding incompatibilities. It looks like this patch simply ignores that problem. What is going to happen to plpython functions that depend on 2.x behavior? 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: James Pye on 12 Nov 2009 20:42 On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote: > Here's the patch to support Python >=3.1 with PL/Python. :\ I was hoping to be able to use Python 3 to draw a clear distinction between plpython and the would-be "plpython3" that I've been working on. I understand that you're not in favor of a brand new implementation for Python 3. Despite my dislike for that position(well, it would seem to be in opposition to my initiative, so naturally =), I don't entirely disagree with your rationale[wrt doing things more incrementally]. For me, plpython has never been what I would call a pleasure to use, and many of the gripes that I have with it are, IMO, entrenched far enough into the implementation that any efforts to change it would(should? =) cause unacceptable breakage in user applications(?). Well, as far as additional Python interfaces are concerned, a lot of redundant functionality, but that's not even the half of it. [I was hoping to get to a status message this weekend, but it seems like I should follow-up here. =] So here's where I'm at: -- Mostly documentation improvements since I last pinged -hackers. Still, *sigh*, filling in documentation and fighting bugs as I go. Currently resolving a bug instantiating MD arrays from nested lists. Once I'm "finished" with the docs, I'm going to start looking for refcount leaks. No major additions or changes are planned, but I have been making some minor additions as I write more docs. Overview/Features: http://wiki.postgresql.org/wiki/WIP:plpython3 Documentation: http://python.projects.postgresql.org/pldocs/plpython3.html git repo[see the plpython3 branch]: http://git.postgresql.org/gitweb?p=plpython3.git;a=summary Most of the documented interfaces have tests. I only have two platforms at my disposal, so I do fear that this will not "just work" on all of PG's supported platforms. Specifically, I've ran the tests on freebsd/amd64 and Mac10.6/intel(of course 10.5 as well for some earlier revisions). [err, actually, it's been a while since I ran the tests on freebsd.] -- plpython3 is turning out to be kinda beefy(~974K diff[eh, there is some fluff in there]), and I can't say that I've seen much interest in it, so I can't really blame anyone if -hackers ends up taking a pass on it. (python3 is too far away for most folk to care? folk are content with plpython?) eh, cheers, either way. =) -- 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: Peter Eisentraut on 13 Nov 2009 03:51 On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e(a)gmx.net> writes: > > 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. > > There was considerable debate earlier about whether we wanted to treat > Python 3 as a separate PL so it could be available in parallel with > plpython 2, because of the user-level coding incompatibilities. It > looks like this patch simply ignores that problem. Exactly how to package that is something to be determined by the packagers, and we can give them the support they need. But first you need code that works with Python 3, which is what this patch does. > What is going to happen to plpython functions that depend on 2.x behavior? The porting path from 2 to 3 is pretty well established. You first port to 2.6, then remove all the old features, then move to 3.x. This is not something we have to reinvent. The only significant differences that you can't use in 2.6 without future imports are unicode literals and the print function, both of which are not in common use in PL/Python. -- 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: Peter Eisentraut on 13 Nov 2009 06:47 On tor, 2009-11-12 at 18:42 -0700, James Pye wrote: > For me, plpython has never been what I would call a pleasure to use, > and many of the gripes that I have with it are, IMO, entrenched far > enough into the implementation that any efforts to change it > would(should? =) cause unacceptable breakage in user applications(?). Has this list of gripes ever been brought up and discussed in this forum? -- 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: James Pye on 13 Nov 2009 13:27
On Nov 13, 2009, at 4:47 AM, Peter Eisentraut wrote: > Has this list of gripes ever been brought up and discussed in this > forum? Some are TODOs, so in part by other people. Some were briefly touched on in the recent past discussions(around the time that I announced the WIP). Native typing vs conversion, function fragments vs function modules. I don't think native typing has seen any actual discussion, but I do recall mentioning it as something that I wanted to do(implicitly griped?). .... There is a difference in the situation from the discussion before. Prior, it was, "I would like to implement a new PL for Python 3 with these features", and now, it is, "I have implemented a new PL for Python 3 with these features". Simply, -hackers can choose among moving forward with Python 3 support in plpython or going with "plpython3" or even both, I suppose(?). Naturally, I'm biased toward something that involves plpython3, so I don't think I can(should?) be of much help to -hackers as a Python & PG user in any such decision. Of course, excepting the provision of justifications for my implementation/design choices... I would really love to see some input from Python users. I certainly don't want to waste time trying to get something into pgsql that Python users don't want. [here's a gripe that I haven't brought up as I think it is a matter of taste] I find (plpython) trigger functions to be a bit odd. I think it's the way in which manipulation/suppression decisions are made in BEFORE ROW triggers(return "OK", "SKIP", etc).. [label this as opinion at this point as I have yet to be able to nail down what, specifically, is "wrong" or un-pythonic about them.] Also, having distinct entry points to handle trigger events helps reduce potential errors by forcing the user to explicitly state the events that the trigger function can handle. Currently, in plpython, users *should* do sanity checks. Function modules opened the door for implementing this in a natural way, multiple functions(entry points) in the function module. http://python.projects.postgresql.org/pldocs/plpython3-programming.html#PLPYTHON3-FUNCTIONS-TRIGGERS -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |