Re: Python 3.1 support - Mailing list pgsql-hackers

From James Pye
Subject Re: Python 3.1 support
Date
Msg-id C191CF54-455F-4454-86DC-F597882D5417@jwp.name
Whole thread Raw
In response to Re: Python 3.1 support  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Python 3.1 support
Re: Python 3.1 support
List pgsql-hackers
On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote:
> The question is whether it helps the user, not the implementer.

Sure, but do you have a patch waiting to implement tracebacks?

I'd argue the reason it's never been done is due to the way procedures are currently managed in PL/Python. And *without
somesignificant refactoring*, any patch fully implementing tracebacks is going to be a seriously ugly hack. 

What helped the implementer here would help the user.

>  As far
> as I can tell, it just creates more typing for no benefit whatsoever.

"def main(*args):" is annoying, but not entirely lamentable...
It's explicit, as well(no need to document munging that occurs behind the scenes).

Also, compare the cases where you need to cache some initialized data:

if 'key' not in SD:...SD['key'] = my_newly_initialized_data
...


With function modules, SD is not needed as you have your module globals to keep your locally cached data in:

...
data = my_newly_initialized_data

def main(*args):...


> Also, it's inconsistent with normal Python script files

Hinges on whether "normal" is actually normal.
I often use the __name__ convention in script files myself:

if __name__ == '__main__':main(...)

That is, using that convention, the script can be import'd and used without executing the "script functionality". (It
hasproven to be very handy a few times now) 

>  and with other PLs.

I don't understand why that's a significant enough interest to note.

> I don't need another PostgreSQL implementation on top of Python.

Indeed, and I do understand that. That is, I have removed some features with that very thought in mind. (OTOH, I
considerthe date_part properties on datetime types to be special: too likely useful.) 

[tho, "PostgreSQL implementation"? I think I understand what you were getting at, but..]

> The maintenance effort required to keep those two consistent aside.

I don't think there are many consistency issues here.
What did you have in mind?

> Again, I'm only one user.  But so far I haven't seen anyone else speak up here, and clearly accepting this for
inclusionwill need nontrivial convincing. 

Agreed. It would seem quite doomed.

At this point, I'm not going to try getting it into PG. (apparent futility and such)

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rejecting weak passwords
Next
From: Tom Lane
Date:
Subject: Re: Rejecting weak passwords