[Python-Dev] Issue 4448
Hello there. I recently reactivated http://bugs.python.org/issue4448 because of the need to port http://bugs.python.org/issue4879 to 3.1 This isn't a straightforward port because of the changes in the IO library. I'd appreciate if someone could shed some light on the comment in line 268 in Lib/http/client.py. See my last comment in the issue for details. Thanks, Kristján ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote: Steven D'Aprano wrote: ... In a generator expression, we have: yielded-expr for-clause if-clause while the corresponding nested statements are: for-clause if-clause yielded-expr The three clauses are neither in the same order, nor are they in reverse order. They are in the same order but rotated, with the last brought around to the front to emphasize it. Did you really not notice that either? There are only three items, of course I noticed that there is *some* rearrangement of the first that leads to the second. Out of the six possible permutations of three items, they can all be described in terms of some sort of reflection, rotation or swap. I don't know how important that correspondence is to language implementers, but as a Python programmer, I'd gladly give up that correspondence (which I don't find that great) in order to simplify exiting a generator expression early. So I like the proposed change. I find it elegant and very Pythonic. +1 for me. Ironically, in a thread cross-posted on c.l.p and elsewhere, someone just labeled Python's comprehension syntax as ad hoc syntax soup. Is that Xah Lee? It sounds like the sort of thing he'd say. That currently is completely wrong. It certainly is wrong. List comps and generator expressions are very elegant, at least to English speakers with a maths background (I personally got list comps once I recognised the correspondence to mathematical set notation. I assumed that was deliberate). It is a carefully designed 1 to 1 transformation between multiple nested statements and a single expression. I'm sure that correspondence is obvious to some, but it wasn't obvious to me, and I don't suppose I'm the only one. That's not a criticism of the current syntax. Far from it -- the current syntax is excellent, regardless of whether or not you notice that it corresponds to a if-loop nested inside a for-loop with the contents rotated outside. But this proposal ignores and breaks that. Using 'while x' to mean 'if x: break' *is*, to me, 'ad hoc'. But it doesn't mean that. The proposed while x has very similar semantics to the while x in a while-loop: break when *not* x. So I detest the proposed change. I find it ugly and anti-Pythonic. To each their own. I find it an elegant extension to the existing syntax. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
It only becomes a problem when someone wants to both support Windows users of their extension modules with pre-built binaries, but *also* doesn't want to set up the appropriate environment for building such binaries (currently a minimum bar of Visual Studio Express on a Windows VM instance). ok - fortunately, thanks to dan kegel for pointing me in the right direction of winetricks vcrun2005p1 i was able to get a successful build using Microsoft.VC8.CRT assemblies. i say successful because Parser/pgen.exe was built and ran, and libpython2.5.dll.a was also successfully built, as was python.exe successfully built. the problem _now_ to overcome is that the bloody libmsvcrt80.a has the wrong definitions, for a 32-bit build! it has functions like _fstat instead of _fstat32 and so on. if this was a 64-bit version of wine i was using mingw32 under, i would not have encountered this issue. amazingly, however, someone _else_ who kindly tried out compiling python2.5 with mingw and msvcr80, native on win32, reported that it was a complete success! as in, successful build, successful install, successful run of tests, only 4 failed regression tests. i am utterly mystified as to how that happened. next task: beat the crap out of libmsvcr80.a and /mingw/include/*.h, repeat until success. l. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Tue, Jan 20, 2009 at 9:19 PM, Martin v. Löwis mar...@v.loewis.de wrote: That's a non-starter for anyone who incorporates Python in an existing MSVC-based development environment. surely incorporating libpython2.5.dll.a or libpython2.6.dll.a, along with the .def and the importlib that's generated with dlldump, unless i'm missing something, would be a simple matter, yes? Not exactly sure what this is, but I believe Python *already* includes such a thing. sorry, martin - i thought the win32 builds generated python25.lib, python25.dll and python25.def so as to fit into the 8.3 filename convention. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
next task: beat the crap out of libmsvcr80.a and /mingw/include/*.h, repeat until success. https://sourceforge.net/tracker/index.php?func=detailaid=2134161group_id=2435atid=352435 roumen, it looks like you've been and done that, already - thank you! ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
On Wed, 21 Jan 2009 at 21:46, Steven D'Aprano wrote: On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote: It is a carefully designed 1 to 1 transformation between multiple nested statements and a single expression. I'm sure that correspondence is obvious to some, but it wasn't obvious to me, and I don't suppose I'm the only one. That's not a criticism of the current syntax. Far from it -- the current syntax is excellent, regardless of whether or not you notice that it corresponds to a if-loop nested inside a for-loop with the contents rotated outside. It wasn't obvious to me until I read this thread, but now that I know about it I feel a huge sense of relief. I was never comfortable with extending (or reading an extension of) a list comprehension beyond the obvious yield/for/if pattern before. Now I have a reliable tool to understand any complex list comprehension. I would not want to lose that! But this proposal ignores and breaks that. Using 'while x' to mean 'if x: break' *is*, to me, 'ad hoc'. But it doesn't mean that. The proposed while x has very similar semantics to the while x in a while-loop: break when *not* x. Half right. 'while x' in the proposed syntax is equivalent to 'if not x: break', But IMO it goes too far to say it has similar semantics to 'while x' in a while loop. Neither while x*x4: for x in range(10): yield x*x nor for x in range(10): while x*x4: yield x*x are the same as for x in range(10): if not x*x4: break yield x*x I understand that you are saying that 'while x' is used in the same logical sense (take a different action when x is no longer true), but that I don't feel that that is enough to say that it has similar semantics. Or, perhaps more accurately, it is just similar enough to be very confusing because it is also different enough to be very surprising. The semantics of 'while' in python includes the bit about creating a loop, and does _not_ include executing a 'break' in the surrounding loop. To give 'while' this new meaning would be, IMO, un-pythonic. (If python had a 'for/while' construct, it would be a different story...and then it would probably already be part of the list comprehension syntax.) So I detest the proposed change. I find it ugly and anti-Pythonic. I'd say +1 except that I don't find it ugly, just un-Pythonic :) --RDM ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
FWIW, there are a few historic languages that implement a compound for-loop: Algol 68, PL/I, SAS et al allow constructs that, if translated to an equivalent (currently invalid) Python-style syntax would look like this for item in iterable while predicate: suite Some also allow for an until keyword. I'm not suggesting that we need to do this in Python; it's just interesting to note that there is some precedent for this approach. On Wed, Jan 21, 2009 at 8:39 AM, rdmur...@bitdance.com wrote: On Wed, 21 Jan 2009 at 21:46, Steven D'Aprano wrote: On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote: It is a carefully designed 1 to 1 transformation between multiple nested statements and a single expression. I'm sure that correspondence is obvious to some, but it wasn't obvious to me, and I don't suppose I'm the only one. That's not a criticism of the current syntax. Far from it -- the current syntax is excellent, regardless of whether or not you notice that it corresponds to a if-loop nested inside a for-loop with the contents rotated outside. It wasn't obvious to me until I read this thread, but now that I know about it I feel a huge sense of relief. I was never comfortable with extending (or reading an extension of) a list comprehension beyond the obvious yield/for/if pattern before. Now I have a reliable tool to understand any complex list comprehension. I would not want to lose that! But this proposal ignores and breaks that. Using 'while x' to mean 'if x: break' *is*, to me, 'ad hoc'. But it doesn't mean that. The proposed while x has very similar semantics to the while x in a while-loop: break when *not* x. Half right. 'while x' in the proposed syntax is equivalent to 'if not x: break', But IMO it goes too far to say it has similar semantics to 'while x' in a while loop. Neither while x*x4: for x in range(10): yield x*x nor for x in range(10): while x*x4: yield x*x are the same as for x in range(10): if not x*x4: break yield x*x I understand that you are saying that 'while x' is used in the same logical sense (take a different action when x is no longer true), but that I don't feel that that is enough to say that it has similar semantics. Or, perhaps more accurately, it is just similar enough to be very confusing because it is also different enough to be very surprising. The semantics of 'while' in python includes the bit about creating a loop, and does _not_ include executing a 'break' in the surrounding loop. To give 'while' this new meaning would be, IMO, un-pythonic. (If python had a 'for/while' construct, it would be a different story...and then it would probably already be part of the list comprehension syntax.) So I detest the proposed change. I find it ugly and anti-Pythonic. I'd say +1 except that I don't find it ugly, just un-Pythonic :) --RDM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.britton%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
- Mensaje original De: Gerald Britton gerald.brit...@gmail.com Para: rdmur...@bitdance.com CC: python-dev@python.org Enviado: miércoles, 21 de enero, 2009 11:38:01 Asunto: Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions FWIW, there are a few historic languages that implement a compound for-loop: Algol 68, PL/I, SAS et al allow constructs that, if translated to an equivalent (currently invalid) Python-style syntax would look like this for item in iterable while predicate: suite Some also allow for an until keyword. I'm not suggesting that we need to do this in Python; it's just interesting to note that there is some precedent for this approach. Well, you could propose changing the for loop syntax (and by extension comprehensions and generators). It's a much more radical proposal, but it does keep consistency across the board, which is one of the major flaws of the PEP in its current form. BTW, there is already an until keyword in python, it's called while not ;) Vitor ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:lt; http://espanol.sports.yahoo.com/ ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
OK then, what is the feeling out there about extending the for syntax in general (and by extension list comprehensions and generator expressions) by adding an optional while clause like this: for item in iterable [while [predicate | not predicate]: suite The predicate would be tested after an item is taken from iterable and before execution of the suite. If the predicate evaluates to false, StopIteration would be raised. This construct would be equivalent to: for item in iterable: if [not predicate | predicate]: break suite Note: this is beyond what I was thinking in the first place, but has arisen from the ensuing discussion. Note 2: this would cover itertools.takewhile but not itertools.dropwhile, AFAICS On Wed, Jan 21, 2009 at 10:27 AM, Vitor Bosshard algor...@yahoo.com wrote: - Mensaje original De: Gerald Britton gerald.brit...@gmail.com Para: rdmur...@bitdance.com CC: python-dev@python.org Enviado: miércoles, 21 de enero, 2009 11:38:01 Asunto: Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions FWIW, there are a few historic languages that implement a compound for-loop: Algol 68, PL/I, SAS et al allow constructs that, if translated to an equivalent (currently invalid) Python-style syntax would look like this for item in iterable while predicate: suite Some also allow for an until keyword. I'm not suggesting that we need to do this in Python; it's just interesting to note that there is some precedent for this approach. Well, you could propose changing the for loop syntax (and by extension comprehensions and generators). It's a much more radical proposal, but it does keep consistency across the board, which is one of the major flaws of the PEP in its current form. BTW, there is already an until keyword in python, it's called while not ;) Vitor ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más: http://espanol.sports.yahoo.com/ ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
The following was supposed to go to the list: 18:29 Gerald Britton: Yes you could have long lines, but you wouldn't have to use it. You could still code it up as you would today. It might be convenient for shorter expressions though. 12:12 PM Ludvig Ericson: On Jan 21, 2009, at 16:51, Gerald Britton wrote: for item in iterable [while [predicate | not predicate]: suite (Sorry for just sort of popping in to the list.) That would make for some very, very long lines. I for one wouldn't like seeing: for cart_item in current_user.cart.new_items \ ... while cart_item.cant_imagine_more: ... body I realize that the other approach--an immediate if-break--wouldn't look great either, but it wouldn't be cramming that much stuff into one line. ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
On Wed, Jan 21, 2009, Gerald Britton wrote: OK then, what is the feeling out there about extending the for syntax in general (and by extension list comprehensions and generator expressions) by adding an optional while clause like this: for item in iterable [while [predicate | not predicate]: suite What I suggest is that your ideas need more thought before bringing them to python-dev -- I think you should either go back to python-ideas or try comp.lang.python -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 8 and constants
In comp.lang.python, there has been some discussion of the fact that there are no guidelines in PEP 8 for constants: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed964fe8ad6da7b7 Is there any sentiment that PEP 8 should be updated to reflect the common usage of ALL_CAPS for constants? -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copyright notices in modules
On Tue, Jan 20, 2009 at 11:01 PM, Terry Reedy tjre...@udel.edu wrote: Guido van Rossum wrote: 2009/1/20 Raymond Hettinger pyt...@rcn.com: I'm at a loss of why the notice needs to be there at all. There's a difference between contributing a whole file and contributing a patch. Patches do not require copyright notices. Whole files do. This is not affected by later edits to the file. In my comment, I postulated the situation where the patch consisted of merging in another, independently copyrighted, 'whole file'. Perhaps this has mostly been a non-existent situation and therefor moot. One real situation I was thinking of, unconnected to Google as far as I am aware, is the case of two third-party IP6 modules and the suggestion that they be merged into one stdlib module. If that were accomplished by committing one and merging the other in a patch, it would be unfair (and untrue) to have just one copyright notice. Of course, in this case, I hope the two authors work everything out between themselves first before any submission. There's nothing top stop you from having multiple copyrights in one file, when that represents the rights of the original authors fairly. I completely understand about strongly preferring programming to lawyer consultation ;-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 8 and constants
On Wed, Jan 21, 2009 at 10:00 AM, Aahz a...@pythoncraft.com wrote: In comp.lang.python, there has been some discussion of the fact that there are no guidelines in PEP 8 for constants: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed964fe8ad6da7b7 Is there any sentiment that PEP 8 should be updated to reflect the common usage of ALL_CAPS for constants? It makes sense to codify this usage in PEP 8. I think it's by far the most common convention adopted by projects that set their own style guide based on PEP 8 with local additions. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vitor Bosshard wrote: Some also allow for an until keyword. I'm not suggesting that we need to do this in Python; it's just interesting to note that there is some precedent for this approach. Well, you could propose changing the for loop syntax (and by extension comprehensions and generators). It's a much more radical proposal, but it does keep consistency across the board, which is one of the major flaws of the PEP in its current form. BTW, there is already an until keyword in python, it's called while not ;) 'until' is used at least in some languages (Pascal, Modula*, maybe Ada?) for a terminate at bottom loop (one guaranteed to run at least once): in such cases, the predicate has the negative sense. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJd3Ff+gerLs4ltQ4RAuOQAJ47EA8Cf1KPMdNiZTBiJqweiUNZBgCgsVrc 38fgphB+hjdnTblAQT8Q5tA= =SeEn -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
sorry, martin - i thought the win32 builds generated python25.lib, python25.dll Correct. and python25.def No. so as to fit into the 8.3 filename convention. No. It generates python25.lib because that's the import library for python25.dll. It calls it python25.dll because the lib prefix is atypical for the platform, and also redundant (DLL means dynamic link library). The Python binary installer also includes libpython25.a, for use with mingw32. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
In article pine.lnx.4.64.0901210811430.14...@kimball.webabinitio.net, rdmur...@bitdance.com wrote: ... I understand that you are saying that 'while x' is used in the same logical sense (take a different action when x is no longer true), but that I don't feel that that is enough to say that it has similar semantics. Or, perhaps more accurately, it is just similar enough to be very confusing because it is also different enough to be very surprising. The semantics of 'while' in python includes the bit about creating a loop, and does _not_ include executing a 'break' in the surrounding loop. To give 'while' this new meaning would be, IMO, un-pythonic. (If python had a 'for/while' construct, it would be a different story...and then it would probably already be part of the list comprehension syntax.) I agree. I feel that the term while is a poor choice for when this is no longer true then stop. It sounds more like a synonym for if to me. I would be much more comfortable using until (in the opposite sense to the proposed while); it clearly implies we're done so stop. I don't know if it's a feature that is really useful, but I do think it would be transparent: code that used it would be easily understood. -- Russell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
this is a progress report on compiling python using entirely free software tools, no proprietary compilers or operating systems involved, yet still linking and successfully running with msvcr80 assemblies. manifests and rc files, which are compiled to internal resources, have been added. various sections which are uniquely identifed by _MSC_VER = 1400 etc have had to be enabled with corresponding MSVCRT_VERSION = 0x0800 - in particular, signal handling (PyOS_getsig()). currently, under wine with msvcr80, there looks like there is a bug with a common theme related to threads, but here's a short list: test_array.py is blocking, test_bz2.py is hanging and test_cmd_line.py causes a segfault; test_ctypes is _still_ a bundle of fun. for those people who use native win32 platforms who are compiling up this code, you should have better luck. significantly, the wine developers have been absolutely fantastic, and have fixed several bugs in wine, sometimes within hours, that were found as a result of running the extremely comprehensive python regression tests. the python regression tests are a credit to the collaborative incremental improvement process of free software development. i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue3754 http://bugs.python.org/issue841454 http://bugs.python.org/issue3871 http://bugs.python.org/issue4954 http://bugs.python.org/issue5010 for those people wishing to track and contribute to the development of python for win32 using entirely free software tools, either under wine or native windows, there is a git repository, here, slightly illogically named pythonwine because that's where i started from (cross-compiling python under wine, so i could get at the wine registry from python). obviously, since then, things have... moved on :) http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine l. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
http://bugs.python.org/issue5010 correction: that's http://bugs.python.org/issue5026 apologies for the mix-up. also,for the msvcrt80 build, it is _essential_ that you use a patched version of mingw32-runtime, see: https://sourceforge.net/tracker/index.php?func=detailaid=2134161group_id=2435atid=352435 libmsvcr80.a mistakenly thinks that _fstat exists (it doesn't - only _fstat32 does, and many more). it's quite straightforward to rebuild - just remember to run ./configure --prefix=/mingw and if you want to revert just reinstall mingw runtime .exe l. ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
Steven D'Aprano wrote: On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote: Steven D'Aprano wrote: The three clauses are neither in the same order, nor are they in reverse order. They are in the same order but rotated, with the last brought around to the front to emphasize it. Did you really not notice that either? There are only three items, of course I noticed that there is *some* rearrangement of the first that leads to the second. Out of the six possible permutations of three items, they can all be described in terms of some sort of reflection, rotation or swap. Irrelevant. *Every* comprehension, no matter how many clauses, rotates the expression from last to first and keeps the clauses in the same order with the same meaning. Simple rule. Ironically, in a thread cross-posted on c.l.p and elsewhere, someone just labeled Python's comprehension syntax as ad hoc syntax soup. Is that Xah Lee? It sounds like the sort of thing he'd say. It was the thread he started, but not him. He contributed other idiocies. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Wed, Jan 21, 2009 at 7:42 PM, Martin v. Löwis mar...@v.loewis.de wrote: sorry, martin - i thought the win32 builds generated python25.lib, python25.dll Correct. and python25.def No. so as to fit into the 8.3 filename convention. No. It generates python25.lib because that's the import library for python25.dll. It calls it python25.dll because the lib prefix is atypical for the platform, and also redundant (DLL means dynamic link library). The Python binary installer also includes libpython25.a, for use with mingw32. ok, so - different from what's being generated by ./configure under msys under wine or native win32 - what's being generated (libpython 2 . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin environment. therefore, there's absolutely no doubt that the two are completely different. and on that basis, would i be correct in thinking that you _can't_ go linking or building modules or any python win32 code for one and have a hope in hell of using it on the other, and that you would _have_ to rebuild e.g. numpy for use with a mingw32-msys-built version of python? or, is the .pyd loading a bit cleverer (or perhaps a bit less cleverer) than i'm expecting it to be? l. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
ok, so - different from what's being generated by ./configure under msys under wine or native win32 - what's being generated (libpython 2 . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin environment. therefore, there's absolutely no doubt that the two are completely different. and on that basis, would i be correct in thinking that you _can't_ go linking or building modules or any python win32 code for one and have a hope in hell of using it on the other, and that you would _have_ to rebuild e.g. numpy for use with a mingw32-msys-built version of python? I can't comment on that, because I don't know what your port does. Does it not produce a .dll containing the majority of Python? And is that not called python25.dll? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Have you made some benchmarks like pystone? Cheers, Cesare On Wed, Jan 21, 2009 08:50PM, Luke Kenneth Casson Leighton wrote: this is a progress report on compiling python using entirely free software tools, no proprietary compilers or operating systems involved, yet still linking and successfully running with msvcr80 assemblies. manifests and rc files, which are compiled to internal resources, have been added. various sections which are uniquely identifed by _MSC_VER = 1400 etc have had to be enabled with corresponding MSVCRT_VERSION = 0x0800 - in particular, signal handling (PyOS_getsig()). currently, under wine with msvcr80, there looks like there is a bug with a common theme related to threads, but here's a short list: test_array.py is blocking, test_bz2.py is hanging and test_cmd_line.py causes a segfault; test_ctypes is _still_ a bundle of fun. for those people who use native win32 platforms who are compiling up this code, you should have better luck. significantly, the wine developers have been absolutely fantastic, and have fixed several bugs in wine, sometimes within hours, that were found as a result of running the extremely comprehensive python regression tests. the python regression tests are a credit to the collaborative incremental improvement process of free software development. i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue3754 http://bugs.python.org/issue841454 http://bugs.python.org/issue3871 http://bugs.python.org/issue4954 http://bugs.python.org/issue5010 for those people wishing to track and contribute to the development of python for win32 using entirely free software tools, either under wine or native windows, there is a git repository, here, slightly illogically named pythonwine because that's where i started from (cross-compiling python under wine, so i could get at the wine registry from python). obviously, since then, things have... moved on :) http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine l. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cesare.dimauro%40a-tono.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions/comments on documentation formatting
Brett Cannon schrieb: I have been writing up the initial docs for importlib and four things struck me: 1. Why is three space indents the preferred indentation level? As said, it matches directive content with directive headers nicely. Ben's solution is nice as well, but now that we have 3-space I'd rather we stick with 3-space (however, if you don't care, I'll not reformat 4-space indents :) Code in code blocks should use 4-space as usual. 2. Should we start using function annotations? It's not really supported yet by Sphinx. Also, I don't know if it makes too much sense, given that it will reinforce the thinking of annotations as type declarations. 3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [, c=None]])``) really necessary when default argument values are present? And do we really need to nest the brackets when it is obvious that having on optional argument means the rest are optional as well? We've discussed that once on the doc-SIG, and I agreed that the bracketing is not really pretty, especially if it's heavily nested. Python functions where it makes sense should use the default-value syntax, while C functions without kwargs support need to keep the brackets. Making this consistent throughout the docs is no small task, of course. 4. The var directive is not working even though the docs list it as a valid directive; so is it still valid and something is broken, or the docs need to be updated? (First, you're confusing directive and role which led to some confusion on Benjamin's part.) Where is a var role documented? If it is, it is a bug. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Terry Reedy wrote: Luke Kenneth Casson Leighton wrote: i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue841454 Against 2.3, rejected due to dependence on SCons. Also appears to have been incomplete, needing more work. No it was complete but use SCons. Most of changes changes in code you will see again in 3871. http://bugs.python.org/issue3754 Open by Roumen Petrov, no review, see below. This is again request and the patch is for trunk. It share common idea with 841454:Cross building python for mingw32:Andreas Ames (yxcv):2003-11-13 14:31 1006238:Cross compile patch:Daniel Goertzen (goertzen):2004-08-09 22:05 1597850:Cross compiling patches for MINGW hanwen:2006-11-16 16:57 http://bugs.python.org/issue3871 Open, from same submitter, only (minor) review by you. Does this supercede 3754? No. It share common changes to code with 841454, 1006238, 1412448, 1597850. May be 1597850 and 3871 supercede 1412448. The issue3871 raise questions (and include solution/work around) related to: 2942 - mingw/cygwin do not accept asm file as extension source 2445 - Use The CygwinCCompiler Under Cygwin 1706863 - Failed to build Python 2.5.1 with sqlite3 Also issues related to LDFLAGS: 4010 - configure options don't trickle down to distutils 1628484 - Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [SNIP] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Where is Fred Drake?
Mail to fdr...@acm.org is bouncing; I don't know whether it's a temporary failure. Does anyone have another address for him? - Forwarded message from Mail Delivery System mailer-dae...@bag.python.org - Date: Wed, 21 Jan 2009 22:48:49 +0100 (CET) From: Mail Delivery System mailer-dae...@bag.python.org Subject: Undelivered Mail Returned to Sender To: webmas...@python.org Content-Description: Notification This is the mail system at host bag.python.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system fdr...@acm.org: host acm.org.s7a1.psmtp.com[64.18.6.14] said: 550 No such user - psmtp (in reply to RCPT TO command) Content-Description: Delivery report Reporting-MTA: dns; bag.python.org X-Postfix-Queue-ID: 24FF41E404E X-Postfix-Sender: rfc822; webmas...@python.org Arrival-Date: Wed, 21 Jan 2009 22:48:48 +0100 (CET) Final-Recipient: rfc822; fdr...@acm.org Original-Recipient: rfc822;fdr...@acm.org Action: failed Status: 5.0.0 Remote-MTA: dns; acm.org.s7a1.psmtp.com Diagnostic-Code: smtp; 550 No such user - psmtp - End forwarded message - -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions/comments on documentation formatting
On Wed, Jan 21, 2009 at 13:53, Georg Brandl g.bra...@gmx.net wrote: Brett Cannon schrieb: I have been writing up the initial docs for importlib and four things struck me: 1. Why is three space indents the preferred indentation level? As said, it matches directive content with directive headers nicely. Ben's solution is nice as well, but now that we have 3-space I'd rather we stick with 3-space (however, if you don't care, I'll not reformat 4-space indents :) =) OK. Code in code blocks should use 4-space as usual. 2. Should we start using function annotations? It's not really supported yet by Sphinx. Also, I don't know if it makes too much sense, given that it will reinforce the thinking of annotations as type declarations. Fine by me. 3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [, c=None]])``) really necessary when default argument values are present? And do we really need to nest the brackets when it is obvious that having on optional argument means the rest are optional as well? We've discussed that once on the doc-SIG, and I agreed that the bracketing is not really pretty, especially if it's heavily nested. Python functions where it makes sense should use the default-value syntax, while C functions without kwargs support need to keep the brackets. That was my thinking. Making this consistent throughout the docs is no small task, of course. Nope, but perhaps all new docs should stop their use. 4. The var directive is not working even though the docs list it as a valid directive; so is it still valid and something is broken, or the docs need to be updated? (First, you're confusing directive and role which led to some confusion on Benjamin's part.) Where is a var role documented? If it is, it is a bug. http://docs.python.org/dev/3.0/documenting/markup.html#inline-markup. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is Fred Drake?
On Wed, Jan 21, 2009 at 6:39 PM, Aahz a...@pythoncraft.com wrote: Mail to fdr...@acm.org is bouncing; I don't know whether it's a temporary failure. Does anyone have another address for him? /me channels Fred: Use freddr...@verizon.net until the acm.org account is back up. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
On 21Jan2009 14:02, Tres Seaver tsea...@palladion.com wrote: | Vitor Bosshard wrote: | BTW, there is already an until keyword in python, it's called while not ;) | | 'until' is used at least in some languages (Pascal, Modula*, maybe Ada?) | for a terminate at bottom loop (one guaranteed to run at least once): | in such cases, the predicate has the negative sense. This is a particular flavour of do ... while which just happens to read a little better in English. It does sometimes bother me that Python doesn't have do...while when I find my self replicating the loop bottom above the loop. Back at uni we had to implement a small language in our compilers class and the lecturer had specified a proper generic while loop, thus: loop: suite while invariant suite endloop I think the keywords were better than above, but it neatly handled the fact that the while-test must often be preceeded by some setup that would be replicated at the loop bottom in Python and many other languages: setup-invariant-state while test-invariant do stuff setup-invariant-state of which the bare while... and converse do...while loops are particular extremes. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Why doesn't DOS ever say EXCELLENT command or filename? ___ Python-Dev mailing list Python-Dev@python.org 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 8 and constants
Yes, that's what I commonly see. On Wed, Jan 21, 2009 at 6:42 PM, Benjamin Peterson benja...@python.org wrote: On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum gu...@python.org wrote: On Wed, Jan 21, 2009 at 10:00 AM, Aahz a...@pythoncraft.com wrote: In comp.lang.python, there has been some discussion of the fact that there are no guidelines in PEP 8 for constants: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed964fe8ad6da7b7 Is there any sentiment that PEP 8 should be updated to reflect the common usage of ALL_CAPS for constants? It makes sense to codify this usage in PEP 8. I think it's by far the most common convention adopted by projects that set their own style guide based on PEP 8 with local additions. Do you suggest underscores between words in constants as with other names? -- Regards, Benjamin -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
Cameron Simpson wrote: Back at uni we had to implement a small language in our compilers class and the lecturer had specified a proper generic while loop, thus: loop: suite while invariant suite endloop In Python, that is spelled while True: suite if not invariant: break suite I think the keywords were better than above, but it neatly handled the fact that the while-test must often be preceeded by some setup that would be replicated at the loop bottom in Python and many other languages: setup-invariant-state while test-invariant do stuff setup-invariant-state Good Python programmers do not repeat the setup code like this. See the proper say-it-once way above. This discussion belongs back on Python ideas, where it began and should have stayed. tjr ___ Python-Dev mailing list Python-Dev@python.org 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 8 and constants
On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum gu...@python.org wrote: On Wed, Jan 21, 2009 at 10:00 AM, Aahz a...@pythoncraft.com wrote: In comp.lang.python, there has been some discussion of the fact that there are no guidelines in PEP 8 for constants: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed964fe8ad6da7b7 Is there any sentiment that PEP 8 should be updated to reflect the common usage of ALL_CAPS for constants? It makes sense to codify this usage in PEP 8. I think it's by far the most common convention adopted by projects that set their own style guide based on PEP 8 with local additions. Ok. I added a note about constants in r68849. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org 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 8 and constants
On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum gu...@python.org wrote: On Wed, Jan 21, 2009 at 10:00 AM, Aahz a...@pythoncraft.com wrote: In comp.lang.python, there has been some discussion of the fact that there are no guidelines in PEP 8 for constants: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed964fe8ad6da7b7 Is there any sentiment that PEP 8 should be updated to reflect the common usage of ALL_CAPS for constants? It makes sense to codify this usage in PEP 8. I think it's by far the most common convention adopted by projects that set their own style guide based on PEP 8 with local additions. Do you suggest underscores between words in constants as with other names? -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org 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 8 and constants
On Wed, Jan 21, 2009, Benjamin Peterson wrote: On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum gu...@python.org wrote: On Wed, Jan 21, 2009 at 10:00 AM, Aahz a...@pythoncraft.com wrote: In comp.lang.python, there has been some discussion of the fact that there are no guidelines in PEP 8 for constants: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed964fe8ad6da7b7 Is there any sentiment that PEP 8 should be updated to reflect the common usage of ALL_CAPS for constants? It makes sense to codify this usage in PEP 8. I think it's by far the most common convention adopted by projects that set their own style guide based on PEP 8 with local additions. Ok. I added a note about constants in r68849. Thanks! -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
Gerald Britton wrote: OK then, what is the feeling out there about extending the for syntax in general (and by extension list comprehensions and generator expressions) by adding an optional while clause like this: for item in iterable [while [predicate | not predicate]: suite The predicate would be tested after an item is taken from iterable and before execution of the suite. If the predicate evaluates to false, StopIteration would be raised. This construct would be equivalent to: for item in iterable: if [not predicate | predicate]: break suite Note: this is beyond what I was thinking in the first place, but has arisen from the ensuing discussion. As Aahz said, this needs to go back to python-ideas or c.l.p to see if it goes anywhere. However, be aware that you're going to need examples from *real code* that show improvements in correctness, readability or speed in order to convince a sufficiently large number of the core devs and/or Guido that such an additional wrinkle to the looping syntax is worth it. A change being clever or cute isn't enough to justify its inclusion - it needs to provide sufficient real world benefit to counter the cost of the feature's development and maintenance, as well as the additional overhead for all users of the language in learning about it. An approach that has been used effectively in the past to argue for new syntax or builtins is to trawl through the standard library and its test suite looking for things that could be simplified by the proposed addition to the language, but appropriate examples could also be drawn from the code bases of other large Python projects (Twisted, Zope, Django, Bazaar, Mercurial... etc). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
Cameron Simpson wrote: On 21Jan2009 14:02, Tres Seaver tsea...@palladion.com wrote: | Vitor Bosshard wrote: | BTW, there is already an until keyword in python, it's called while not ;) | | 'until' is used at least in some languages (Pascal, Modula*, maybe Ada?) | for a terminate at bottom loop (one guaranteed to run at least once): | in such cases, the predicate has the negative sense. This is a particular flavour of do ... while which just happens to read a little better in English. It does sometimes bother me that Python doesn't have do...while when I find my self replicating the loop bottom above the loop. Adding a do-while construct to Python has already been proposed: http://www.python.org/dev/peps/pep-0315/ It was merely deferred due to only garnering lukewarm support and lack of a reference implementation rather than actually being rejected: http://mail.python.org/pipermail/python-dev/2006-February/060718.html Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org 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 3142: Add a while clause to generator expressions
Terry Reedy wrote: Steven D'Aprano wrote: Is that Xah Lee? It sounds like the sort of thing he'd say. It was the thread he started, but not him. He contributed other idiocies. Xah Lee is still around? I would have expected him to get bored and go away years ago... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
