plpython3
in [PgSql]
|
From: Josh Berkus on 13 Jan 2010 13:16 > My argument would be now, what is the benefit of the James Pye version > over our version. James can you illustrate succinctly why we should be > supporting a new version? > > If there is, I am still all for it, but I am a python bigot. Yeah, it's just my viewpoint that we don't want 2 python procedural languages in core. One should be in core, and one should go on pgFoundry/PGAN. Which ever one is "better" by some clear definition should go in core. As I said, I have no opinion about whether Pye's PLpython should replace the existing because I'm in no position to judge. --Josh Berkus -- 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: Robert Haas on 13 Jan 2010 14:15 On Wed, Jan 13, 2010 at 1:16 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > >> My argument would be now, what is the benefit of the James Pye version >> over our version. James can you illustrate succinctly why we should be >> supporting a new version? >> >> If there is, I am still all for it, but I am a python bigot. > > Yeah, it's just my viewpoint that we don't want 2 python procedural > languages in core. One should be in core, and one should go on > pgFoundry/PGAN. Which ever one is "better" by some clear definition > should go in core. That was my thinking also. There are a couple of reasons to think that throwing over the current implementation for an new one may not be the right thing to do. 1. It's not just a rewrite, it's an incompatible rewrite that will present significant user-visible behavioral differences. So replacing the current implementation wholesale would produce massive breakage for anyone actually using PL/python in production. 2. Peter Eisentraut, who has put significant time into improving PL/python for this release (see the commit logs), and who is the ONLY committer to work on improving PL/python for this release, has made it clear that he prefers the current implementation. Given these two facts, it's hard for me to see how we could decide to REMOVE the current implementation and replace it with the new one. So the most we could do is maintain them side by side, and then you have to ask, why? It will actually be much easier for James Pye to maintain his code outside core, and if it turns out to be popular and people come back to us and say "hey, why isn't this the default?" then we can revisit the issue. Sure, his code won't get as much exposure that way, but it's been posted to the mailing list several times now over a period of 8 months and nobody has said "oh, wow, this is great". The most we've gotten is several versions of this exchange: Somebody: We should really consider this code, the current code isn't very good. Peter: What's wrong with it? Somebody: <describes some problem, usually fairly vaguely> Peter: Why can't we fix that in the existing code base? <thread ends> I'm not saying a complete rewrite isn't the way to go - I'm just saying that there isn't much evidence at this point that it's really necessary, and I don't think we want to maintain two copies of PL/python unless we're really sure that the new implementation is an improvement. ....Robert -- 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 William Pye on 13 Jan 2010 15:06 On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote: > My argument would be now, what is the benefit of the James Pye version > over our version. James can you illustrate succinctly why we should be > supporting a new version? Doing so, succinctly, is unfortunately difficult. It is primarily a matter of comparing features, AFAICT. And, furthermore, some features may not be useful to some users. It exposes additional functionality that should *not* be incrementally developed in plpython as it would break applications. This was the point of trying to move forward with it for Python 3. Function Modules: - Does away with the need for GD/SD (more natural Python environment). - Allows tracebacks (tracebacks are useful, right?) to implemented easily. - Does *not* expose a bastardized variant of the language by pretending that "modules/script files" can return and yield. - Helps to promote the Python tenet of being explicit. Native Typing: - Provides PG type introspection not available in any other PL, AFAIK. - Improves efficiency in some cases (conversion must be _explicitly_ called for) - MD Array support. - Composites are a sequence and a mapping. Other features: http://wiki.postgresql.org/wiki/WIP:plpython3 Aside from function modules and native typing, many of plpython3's features could be implemented incrementally. However, I had a chance to sprint and they are available now in a new implementation. I did so, rather than improving plpython, because I believe that native typing and function modules are very useful. I'm not sure this fulfills your request, but, hopefully, it's a start. -- 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 13 Jan 2010 15:12 On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote: > On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote: > > My argument would be now, what is the benefit of the James Pye version > > over our version. James can you illustrate succinctly why we should be > > supporting a new version? > > > Doing so, succinctly, is unfortunately difficult. > It is primarily a matter of comparing features, AFAICT. And, furthermore, some features may not be useful to some users. > > It exposes additional functionality that should *not* be incrementally developed in plpython as it would break applications. This was the point of trying to move forward with it for Python 3. > > Function Modules: > - Does away with the need for GD/SD (more natural Python environment). > - Allows tracebacks (tracebacks are useful, right?) to implemented easily. > - Does *not* expose a bastardized variant of the language by pretending that "modules/script files" can return and yield. > - Helps to promote the Python tenet of being explicit. > > Native Typing: > - Provides PG type introspection not available in any other PL, AFAIK. > - Improves efficiency in some cases (conversion must be _explicitly_ called for) > - MD Array support. > - Composites are a sequence and a mapping. > > Other features: http://wiki.postgresql.org/wiki/WIP:plpython3 > > > Aside from function modules and native typing, many of plpython3's features could be implemented incrementally. However, I had a chance to sprint and they are available now in a new implementation. I did so, rather than improving plpython, because I believe that native typing and function modules are very useful. > > I'm not sure this fulfills your request, but, hopefully, it's a start. It does actually. Now, hackers... as a Python guy I can say these things are truly useful, to a Python programmer trying to use Python as a procedural language with PostgreSQL. What do we think? Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- 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 Jan 2010 16:27
On ons, 2010-01-13 at 12:12 -0800, Joshua D. Drake wrote: > On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote: > > Function Modules: > > - Does away with the need for GD/SD (more natural Python environment). > > - Allows tracebacks (tracebacks are useful, right?) to implemented easily. > > - Does *not* expose a bastardized variant of the language by pretending that "modules/script files" can return and yield. > > - Helps to promote the Python tenet of being explicit. > > > > Native Typing: > > - Provides PG type introspection not available in any other PL, AFAIK. > > - Improves efficiency in some cases (conversion must be _explicitly_ called for) > > - MD Array support. > > - Composites are a sequence and a mapping. > > > > Other features: http://wiki.postgresql.org/wiki/WIP:plpython3 > > > > > > Aside from function modules and native typing, many of plpython3's features could be implemented incrementally. However, I had a chance to sprint and they are available now in a new implementation. I did so, rather than improving plpython, because I believe that native typing and function modules are very useful. > > > > I'm not sure this fulfills your request, but, hopefully, it's a start. > > It does actually. Now, hackers... as a Python guy I can say these things > are truly useful, to a Python programmer trying to use Python as a > procedural language with PostgreSQL. The problem I'm having with this discussion is that every time someone asks what the supposed advantages of this new Python PL are, a feature list like the above is dumped, 75% of which is subjective and tends to use semi-buzzwords, such that then someone else who by his own admission isn't completely up to date on things says, sure, that sounds great. Who wouldn't like a "more natural Python environment", "native typing" and "efficiency", and maybe even "explicitness"? The current PL/Python also has, arguably, a more natural Python environment, native typing, efficiency, and explicitness. So there you go. Now what? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |