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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to