Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
> I saw them. Your brain must be wired very differently > to mine, because I find loops with a continue in them > harder to follow than ones without -- exactly the > opposite of what you seem to prefer. Delurking for no particular reason: For what it's worth, I also favor the continue syntax Heiko compared his code against. Without it, you have to scroll to the end of the loop to know whether there is an else clause; it also allows you to have multiple conditions expressed up-front without a lot of indentation. In general, I favor the idea that the main flow of computation should have the least indentation. I also am +1 on this PEP, even if it is doomed, as I've often longed to use list- comprehension like syntax in a for loop; to me it is mentally taxing to remember which syntax is supported where. Just thought I'd throw Heiko some support. :) Niko ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt
Tim> If there's no functionality changes, what would be the problem with Tim> putting it in post-alpha? It still represents new code that may introduce new bugs. In theory (and generally in practice for Python), once you move into the beta stage all you do is fix bugs. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt
On 5/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Tim> If there's no functionality changes, what would be the problem withTim> putting it in post-alpha?It still represents new code that may introduce new bugs. In theory (andgenerally in practice for Python), once you move into the beta stage all you do is fix bugs.Note that the problem isn't 'post-alpha', it's 'post-beta' -- new features (especially minor or long-agreed-upon) are fine up until beta1 ;)-- Thomas Wouters < [EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterating generator from C (PostgreSQL's pl/python RETUN SETOF/RECORD iterator support broken on RedHat buggy libs)
I try to move this to -dev as I hope there more people reading it who
are competent in internal working :). So please replay to -dev only.
-
The question is about use of generators in embedde v2.4 with asserts
enabled.
Can somebody explain, why the code in try2.c works with wrappers 2 and 3
but crashes on buggy exception for all others, that is pure generator
and wrappers 1,4,5 ?
In other words, what does [i in i for gen] do differently than other
ways of iterating over gen, which helps it to avoid the assert, and
also, how could I write something that is still a generator, but does
not trigger the assert.
While the right solution is to just fix python (which is done for v2.5)
we need a workaround for the following reason
We have added support for returning rows (as tuples and or dictionaries
or classes) and sets of boths scalars and rows to PostgreSQL's
pl/plpython embedded language, but have some objections to getting this
into distribution, because there is a bug in python 2.4 doing a wrong
assert and additional bug in how RedHat rpm build process which leaves
the buggy asserts in python.so.
So I hoped to write a simple wrapper class, but it only seems to work,
when the generator is turned into list, which is not a good solution as
it works directly against what generators are good for.
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
#include
#include
const char *py_source =
"def fn():\n"
"print 'one'\n"
"yield 1\n"
"print 'two'\n"
"yield 2\n"
;
const char *wrapper_source1 =
"class gwrap:\n"
"def __init__(self,gen):\n"
"self.gen = gen\n"
"def __iter__(self):\n"
"return iter(self.gen)\n"
;
const char *wrapper_source2 =
"def gwrap(gen):\n"
"return [i for i in gen]\n"
;
const char *wrapper_source3 =
"def gwrap(gen):\n"
"return (x for x in [i for i in gen])\n"
;
const char *wrapper_source4 =
"class gwrap:\n"
"def __init__(self,gen):\n"
"list = [i for i in gen]\n"
"self.gen = list.__iter__()\n"
"def __iter__(self):\n"
"return iter(self.gen)\n"
;
const char *wrapper_source5 =
"def gwrap(gen):\n"
"return (i for i in gen)\n"
;
int main (int argc, char *argv[])
{
Py_Initialize();
PyObject *main_module = PyImport_AddModule("__main__");
PyObject *globals = PyObject_GetAttrString( main_module, "__dict__");
// insert function code into interpreter
PyObject *code = PyRun_String(py_source, Py_file_input, globals, NULL);
Py_DECREF(code);
// insert wrapper class into interpreter
PyObject *code2 = PyRun_String(wrapper_source5, Py_file_input, globals, NULL);
Py_DECREF(code2);
// compile call to the function
code = Py_CompileString("gwrap(fn())", "", Py_eval_input);
// code = Py_CompileString("fn()", "", Py_eval_input);
// do call
PyObject *gen = PyEval_EvalCode((PyCodeObject *)code, globals, NULL);
gen = PyObject_GetIter((PyObject *)gen);
// iterate result
PyObject *item;
while ((item = PyIter_Next(gen))) {
printf("> %ld\n", PyInt_AsLong(item));
Py_DECREF(item);
}
Py_DECREF(gen);
Py_DECREF(code);
Py_DECREF(globals);
Py_Finalize();
return 0;
}
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Niko Matsakis <[EMAIL PROTECTED]> wrote: > > > I saw them. Your brain must be wired very differently > > to mine, because I find loops with a continue in them > > harder to follow than ones without -- exactly the > > opposite of what you seem to prefer. > > Delurking for no particular reason: > > For what it's worth, I also favor the continue syntax Heiko compared > his code against. Without it, you have to scroll to the end of the > loop to know whether there is an else clause; it also allows you to One could also consider documenting the fact that there is no else clause... for i in ...: if ...: #no else clause ... - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Heiko Wundram <[EMAIL PROTECTED]> wrote: > Why isn't this good practice? It's not always sensible to refactor loop code > to call methods (to make the loop body shorter), and it's a pretty general > case that you only want to iterate over part of a generator, not over the > whole content. Because of this, list comprehensions grew the 'if'-clause. So: > why doesn't the for-loop? List comprehensions grew an if clause because they are expressions that were supposed to replace one of the most the most common idioms in Python: x = [] for i in ...: if ...: x.append(...) And you know what? They've done that very well. Seemingly so well that you are asking for the list comprehension syntax to make it back into for loops. So far, you have failed to convince me (and most others it looks like) that it is a good idea, you have re-hashed the same arguments you made in the PEP, and Guido chimed in as the first message to say: "-1. The contraction just makes it easier to miss the logic." "This was proposed and rejected before." - Guido If you want some advice: let it drop. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >I'd like to include paste.lint with that as well (as wsgiref.lint or >whatever). Since the last discussion I enumerated in the docstring all >the checks it does. There's still some outstanding issues, mostly where >I'm not sure if it is too restrictive (marked with @@ in the source). >It's at: > >http://svn.pythonpaste.org/Paste/trunk/paste/lint.py Ian, I see this is under the MIT license. Do you also have a PSF contributor agreement (to license under AFL/ASF)? If not, can you place a copy of this under a compatible license so that I can add this to the version of wsgiref that gets checked into the stdlib? (And if any PSF folks can chime in with easier ways to handle this, please do.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt
Thomas Wouters wrote: > On 5/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Tim> If there's no functionality changes, what would be the > problem with Tim> putting it in post-alpha? > > It still represents new code that may introduce new bugs. In theory > (and > generally in practice for Python), once you move into the beta stage > all you > do is fix bugs. > > > Note that the problem isn't 'post-alpha', it's 'post-beta' -- new > features (especially minor or long-agreed-upon) are fine up until > beta1 ;) Isn't "beta" post-alpha? I did of course mean once we were out of the alpha stage. If they're purely performance changes (no new functionality) then there's no problem with putting it in during beta - IMO even if it introduces new bugs (so long as those bugs are gone by the time 2.5 goes final). Beta is "feature set frozen". Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement andlist-comp syntax
Niko Matsakis wrote: > For what it's worth, I also favor the continue syntax Heiko compared > his code against. I also commonly do early tests and either break or continue, but my criteria is whether it makes the flow easier to understand. Sometimes it does, sometimes it doesn't. (on two lines of course ;) where things are considerably more complex > In general, I favor the idea that the main flow of > computation should have the least indentation. Ditto, simply because it tends to be more readable. > I also am +1 on this > PEP, even if it is doomed, as I've often longed to use list- > comprehension like syntax in a for loop; to me it is mentally taxing > to remember which syntax is supported where. > > Just thought I'd throw Heiko some support. :) I'm -1 because there are numerous other ways to do it that are just as clear IMO. No support from me Heiko ;) Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Niko Matsakis <[EMAIL PROTECTED]> wrote: > For what it's worth, I also favor the continue syntax Heiko compared > his code against. Without it, you have to scroll to the end of the > loop to know whether there is an else clause; Only if the code doesn't fit on one screen, which it should. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Charles Waldman?
Hi Skip, Did you ever find Charles Waldman? We are looking for him too. Monica ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Looking for Memories of Python Old-Timers
How long have you used Python? 10 years or longer? Please tell us how you first heard of the language, how you first used it, and how you helped develop it (if you did). More recent reminiscences are welcome too! Please add them to my blog: http://www.artima.com/weblogs/viewpost.jsp?thread=161207 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
Phillip J. Eby wrote: > At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >> I'd like to include paste.lint with that as well (as wsgiref.lint or >> whatever). Since the last discussion I enumerated in the docstring all >> the checks it does. There's still some outstanding issues, mostly where >> I'm not sure if it is too restrictive (marked with @@ in the source). >> It's at: >> >>http://svn.pythonpaste.org/Paste/trunk/paste/lint.py > > Ian, I see this is under the MIT license. Do you also have a PSF > contributor agreement (to license under AFL/ASF)? If not, can you place > a copy of this under a compatible license so that I can add this to the > version of wsgiref that gets checked into the stdlib? I don't have a contributor agreement. I can change the license in place, or sign an agreement, or whatever; someone should just tell me what to do. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
This explains what to do, and which license to use: http://www.python.org/psf/contrib/ --Guido On 5/22/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: > >> I'd like to include paste.lint with that as well (as wsgiref.lint or > >> whatever). Since the last discussion I enumerated in the docstring all > >> the checks it does. There's still some outstanding issues, mostly where > >> I'm not sure if it is too restrictive (marked with @@ in the source). > >> It's at: > >> > >>http://svn.pythonpaste.org/Paste/trunk/paste/lint.py > > > > Ian, I see this is under the MIT license. Do you also have a PSF > > contributor agreement (to license under AFL/ASF)? If not, can you place > > a copy of this under a compatible license so that I can add this to the > > version of wsgiref that gets checked into the stdlib? > > I don't have a contributor agreement. I can change the license in > place, or sign an agreement, or whatever; someone should just tell me > what to do. > > > -- > Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c P
On 5/22/06, martin.v.loewis <[EMAIL PROTECTED]> wrote: > Author: martin.v.loewis > Date: Mon May 22 11:15:18 2006 > New Revision: 46064 > > Modified: python/trunk/Include/Python.h > == > --- python/trunk/Include/Python.h (original) > +++ python/trunk/Include/Python.h Mon May 22 11:15:18 2006 > @@ -35,7 +35,9 @@ > #endif > > #include > +#ifndef DONT_HAVE_ERRNO_H > #include > +#endif > #include > #ifdef HAVE_UNISTD_H > #include What is the reason for the DONT_HAVE_* macros? Can we use the HAVE_* versions? There only seem to be 22 occurrences total: Include/pyport.h:6 Modules/arraymodule.c:2 Modules/getbuildinfo.c:1 Modules/selectmodule.c:1 Objects/fileobject.c:3 PC/pyconfig.h:2 Python/ceval.c:1 Python/mystrtoul.c:1 Python/strtod.c:1 Python/thread.c:1 RISCOS/pyconfig.h:3 n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
It's not clear to me whether this means that Ian can just relicense his code for me to slap into wsgiref and thence into Python by virtue of my own PSF contribution form and the compatible license, or whether it means Ian has to sign a form too. At 09:25 PM 5/22/2006 -0700, Guido van Rossum wrote: >This explains what to do, and which license to use: > >http://www.python.org/psf/contrib/ > >--Guido > >On 5/22/06, Ian Bicking <[EMAIL PROTECTED]> wrote: >>Phillip J. Eby wrote: >> > At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >> >> I'd like to include paste.lint with that as well (as wsgiref.lint or >> >> whatever). Since the last discussion I enumerated in the docstring all >> >> the checks it does. There's still some outstanding issues, mostly where >> >> I'm not sure if it is too restrictive (marked with @@ in the source). >> >> It's at: >> >> >> >>http://svn.pythonpaste.org/Paste/trunk/paste/lint.py >> > >> > Ian, I see this is under the MIT license. Do you also have a PSF >> > contributor agreement (to license under AFL/ASF)? If not, can you place >> > a copy of this under a compatible license so that I can add this to the >> > version of wsgiref that gets checked into the stdlib? >> >>I don't have a contributor agreement. I can change the license in >>place, or sign an agreement, or whatever; someone should just tell me >>what to do. >> >> >>-- >>Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org >>___ >>Python-Dev mailing list >>[email protected] >>http://mail.python.org/mailman/listinfo/python-dev >>Unsubscribe: >>http://mail.python.org/mailman/options/python-dev/guido%40python.org > > >-- >--Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
Anthony's schedule is a bit up in the air which means this schedule does not reflect what reality will be. Perhaps we will skip a3 altogether which will give more time in a sense, though not in reality since b1 in that case will hopefully be on or before June 14. FWIW: alpha 3: May 25, 2006 [planned] beta 1: June 14, 2006 [planned] beta 2: July 6, 2006 [planned] rc 1:July 27, 2006 [planned] final: August 3, 2006 [planned] As for wanting to get more things in, people ought to communicate that here. If there's something that should be added to the PEP, everyone needs to know. n -- On 5/21/06, Aahz <[EMAIL PROTECTED]> wrote: > On Sun, May 21, 2006, Neal Norwitz wrote: > > On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > >> > >>Remember, the feature freeze isn't until beta1. New stuff can still go > >>in after the next alpha, before beta1. > > > > I agree. Of course, it's preferable to get things in ASAP to get more > > testing. > > Nevertheless, I still think that putting out an alpha during or right > before a major sprint is awkward at best. My testing is more focused on > alpha releases than the trunk, and I think other people work similarly. > Except for Anthony, the responses you've gotten to this surprising > change have been negative; this doesn't seem in keeping with our usual > decision-making process. > > BTW, the PEP on python.org hasn't been updated. Please post the current > schedule here. > -- > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > "I saw `cout' being shifted "Hello world" times to the left and stopped > right there." --Steve Gonedes > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
[Phillip J. Eby] > It's not clear to me whether this means that Ian can just relicense his > code for me to slap into wsgiref and thence into Python by virtue of my own > PSF contribution form and the compatible license, or whether it means Ian > has to sign a form too. It's clearly best if Ian signs a form: as http://www.python.org/psf/contrib/ explained, one of the primary aims of the PSF form is to give the PSF legal right to _re_license the work. You have no such right if Ian merely licenses his code to you, and so also no basis on which you can represent that the PSF can relicense the portions of your work derived from Ian's. If Ian can sign a PSF form, that keeps the legalities as clear as possible. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c P
Neal Norwitz wrote: > What is the reason for the DONT_HAVE_* macros? Can we use the HAVE_* > versions? I think the actual rationale is that the contributor didn't want to be bothered with modifying configure.in, and running autoconf. I accepted the change since systems which don't have, say, , are "unusual", in the sense that they aren't standard C systems (as standard C mandates errno.h, atleast in a hosted environment). So far, only one target platform doesn't have these things (Windows CE), so the reasoning is that the burden of setting things right should be on that system. Of course, it would be fairly straight-forward to convert this to standard autoconf machinery (if one remembers to update PC/pyconfig.h accordingly). I'm sure Luke Dunstan would be willing to revise the patch in that direction if that is agreed. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
Neal Norwitz wrote: > Anthony's schedule is a bit up in the air which means this schedule > does not reflect what reality will be. Perhaps we will skip a3 > altogether which will give more time in a sense, though not in reality > since b1 in that case will hopefully be on or before June 14. FWIW: > > alpha 3: May 25, 2006 [planned] > beta 1: June 14, 2006 [planned] > beta 2: July 6, 2006 [planned] > rc 1:July 27, 2006 [planned] > final: August 3, 2006 [planned] > > As for wanting to get more things in, people ought to communicate that > here. If there's something that should be added to the PEP, everyone > needs to know. If alpha 3 doesn't happen until May 27 (which is what the PEP on the Web *still* says, can somebody please fix the build process so that it actually gets installed?), it should get dropped entirely. I'm not available for creating installers in the following week, so the earliest day to make alpha 3 would then be June 5, but traditionally, it would be June 8. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
