From: | James Pye <lists(at)jwp(dot)name> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Python 3.1 support |
Date: | 2009-11-18 20:36:06 |
Message-ID: | C191CF54-455F-4454-86DC-F597882D5417@jwp.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 some significant 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 has proven 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 consider the 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 inclusion will 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-18 22:05:34 | Re: Rejecting weak passwords |
Previous Message | Tom Lane | 2009-11-18 20:05:34 | Re: Rejecting weak passwords |