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
featurelists, 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
bythe 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 /
scriptfiles" 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'tthe case, I wouldn't call it anything--save "[data] conversion" when necessary--as it wouldn't be much of a
featureto 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
onhow the parameters / query results are used.
Although, as stated before, the difference in efficiency can be rather significant in situations where conversion to
built-inPython 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
givesome 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.