plpython3
in [PgSql]
|
From: "Joshua D. Drake" on 13 Jan 2010 16:33 On Wed, 2010-01-13 at 23:27 +0200, Peter Eisentraut wrote: > 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? Peter, are you interested in the benefit of the project, or your own ego? Take it easy and let's see if we can be productive here. I was just stating that James's explanation was good and looking for more information from a reviewer. Secondly nobody (at least I am not) is suggesting we dump the current PL/Python, so your hard work is not going to be lost. The only thing I am currently looking for is an objective review of the patch based on the benefits it provides. I can tell you that if the Pye patch provides stack trace capability and the current PL does not. That right there is enough for me to push a +1 for review and possible inclusion. If you feel what James is saying is actually trite and more buzzword compliant I welcome the opportunity to see a comparative of the current status of PL/Python versus the Pye patch from you. If nothing else it is a learning opportunity for all involved. Sincerely, 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:46 On ons, 2010-01-13 at 13:33 -0800, Joshua D. Drake wrote: > The only thing I am currently looking for is an objective review of the > patch based on the benefits it provides. Right, but I was opining that such a vague feature listing is not adequate for that. > I can tell you that if the Pye > patch provides stack trace capability and the current PL does not. That > right there is enough for me to push a +1 for review and possible > inclusion. That is the case. > If you feel what James is saying is actually trite and more buzzword > compliant I welcome the opportunity to see a comparative of the current > status of PL/Python versus the Pye patch from you. If nothing else it is > a learning opportunity for all involved. There was extensive discussion about some of the design decisions upthread, so any reviewer should review those. It may end up being a agree-to-disagree situation. -- 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 23:12 On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote: > 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, I agree that this is unfortunate, but how else can we to discuss the advantages? It boils down to comparing a couple feature lists, and *maybe* some implementation details. No? > 75% of which is subjective and tends to use semi-buzzwords, You say "semi-buzzwords", I say "names". I have to call "it" something. > such that then someone else who by his own admission > isn't completely up to date on things says, sure, that sounds great. Which is why we need to get some more experienced Python users involved in this. Well, even the mileage of inexperienced users is quite useful for detecting what level of obviousness has been achieved by the features, so I'm not trying to exclude anyone. > The current PL/Python also has, arguably, a more natural Python environment, No, it doesn't. GD/SD are contrived in order to compensate for the very absence of that. Additionally, "modules / script files" don't return or yield. > native typing, Okay, that's arguably subjective, but when I write "native typing", it's wrt PG, not Python's built-in types. If that wasn't the case, I wouldn't call it anything--save "[data] conversion" when necessary--as it wouldn't be much of a feature to clamor about. > efficiency, Yes, as discussed in the thread before there are trade-offs here wrt how PG data is handled. It depends pretty heavily on how the parameters / query results are used. Although, as stated before, the difference in efficiency can be rather significant in situations where conversion to built-in Python types is *not* desired. > and explicitness. Hrm? What is explicit about munging the source code of the procedure to make it into a function body? Perhaps you could give some examples where plpython helps promote explicitness? And sure, I understand that other PLs do this. That may be fine for those languages, but for Python it's not, IMO. -- 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 23:39 On Jan 13, 2010, at 12:15 PM, Robert Haas wrote: > 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. Right. That was the point of trying to leverage Python 3 to make the distinction. Most people will need to update their functions if they are moving to Python 3. And for the larger chunks of code, the hard stuff, the amount of change required is likely significant already. <snip some> > 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? My original hope was that plpython would be maintained for several years to come and when Python 3 started picking up steam, we would deprecate plpython. If people still wanted to use it, they could continue using the older version of PG and/or someone could continue to maintain plpython out of core for legacy support. <snip/maintaining out of core> > Sure, his code won't get as much exposure that way, =) Try next to none. The existence of core's implementation makes competing *very* difficult, IMO. Thinking of something along the lines: "Why would I use/contribute to your implementation when core has one?" And, all I can say in response is, "Check out my features." Subsequently, they will probably weigh the added risk of choosing the loner's implementation and come to the conclusion that using core's would be safer in the long term. I can't fault that line of reasoning, so ISTM that it would be difficult to "sell". > 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". Yeah. :( In the past, one person showed interest in function modules(Stuart, see the first WIP message), and two others showed interest in native typing(Nathan and Tino). Mr. Drake has also shown some interest in this thread. But, yes, you are correct. There has been no "wow, this is great" message. -- 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: Greg Smith on 14 Jan 2010 02:17
James William Pye wrote: > On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote: > >> 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, >> > > I agree that this is unfortunate, but how else can we to discuss the advantages? It boils down to comparing a couple feature lists, and *maybe* some implementation details. No? > Code samples. You're trying to unseat a well established incumbent here, and you're not ever going to do that with documentation. Maybe your plpython3 has some compelling features to it. I don't know, because even with several thousand lines of basic Python code to my credit I cannot understand a single one of the arguments you presented for why your implementation is better--except agreeing that, yes, tracebacks are useful And even on that one, I'm not going to take your word on the superiority of your implementation. You're writing way over people's heads here. (Doesn't help that your docs link at the bottom of http://wiki.postgresql.org/wiki/WIP:plpython3 is broken either). If one has to be a Python expert to understand your position, you've already lost. Python code is easy to read though. If you'd said "here's a great example of how Function Modules are an improvement over what you can do with the current pl/python," that would be infinitely more useful than the list of language trivia related to them. You should be aiming to put Peter on the spot to respond to claims you make like "you can't do this easily with the current implementation" after showing an elegant bit of code. One of the things I'm increasingly frustrated by (and don't take this personally, this is a general comment coming more from the last CF rather than something I mean to single you out for) is how many patch submissions we get that don't have *compelling* examples showing their value. Have a better programming approach to something? Show me the old way and how the new way is better. Performance improvement? Provide a complete, self-contained example showing how to demonstrate it. New type of feature? Cut and paste a whole session showing how it's used, with every single command you typed after initdb. Basically, if a reviewer can't confirm your patch is doing something useful in five minutes and be excited that they've watched something interesting happen, you're decreasing the chances that your patch will ever go anywhere dramatically. I hope that everyone submitting patches reads http://www.depesz.com/ at least once in a while. One of the things I really enjoy about his blog is how he shows complete working examples of so many patches. To pick a standout recent entry, http://www.depesz.com/index.php/2010/01/03/waiting-for-8-5-exclusion-constraints/ takes "exclusion constraints"--a feature I didn't follow a bit of the discussion about--and works through the whole feature with a series of examples that, while still complicated, are completely self-contained and possible to follow along until you understand how it all fits together. Patch submitters should consider it a goal to make life that easy for the reviewer stuck with checking their patch out. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com |