[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 [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 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 [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] 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 [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] 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" 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 [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] 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=detail&aid=2134161&group_id=2435&atid=352435 roumen, it looks like you've been and done that, already - thank you! ___ 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 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*x<4:
for x in range(10):
yield x*x
nor
for x in range(10):
while x*x<4:
yield x*x
are the same as
for x in range(10):
if not x*x<4: 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
[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 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 in while :
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, 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*x<4:
>for x in range(10):
>yield x*x
>
> nor
>
>for x in range(10):
>while x*x<4:
>yield x*x
>
> are the same as
>
>for x in range(10):
>if not x*x<4: 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
> [email protected]
> 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
[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 3142: Add a "while" clause to generator expressions
- Mensaje original > De: Gerald Britton > Para: [email protected] > CC: [email protected] > 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 in while : > > > > 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 [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 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 in [while [ | not ]: The predicate would be tested after an is taken from and before execution of the . If the predicate evaluates to false, StopIteration would be raised. This construct would be equivalent to: for in : if [not | ]: break 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 wrote: > - Mensaje original >> De: Gerald Britton >> Para: [email protected] >> CC: [email protected] >> 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 in while : >> >> >> >> 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 [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 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 in [while [ | not ]: (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: ... 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 [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 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 in [while [ | not ]: > 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 ([email protected]) <*> 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 [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] 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 ([email protected]) <*> 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 [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] Copyright notices in modules
On Tue, Jan 20, 2009 at 11:01 PM, Terry Reedy wrote: > Guido van Rossum wrote: >> >> 2009/1/20 Raymond Hettinger : >>> >>> 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 [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 8 and constants
On Wed, Jan 21, 2009 at 10:00 AM, Aahz 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 [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 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 [email protected] Palladion Software "Excellence by Design"http://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 [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] 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 [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 3142: Add a "while" clause to generator expressions
In article , [email protected] 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 [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] 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 [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] 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=detail&aid=2134161&group_id=2435&atid=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 [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 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 [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] 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" 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 [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] 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 [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] 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 > [email protected] > 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 [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] 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 [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] 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 [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] Where is Fred Drake?
Mail to [email protected] 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 - > Date: Wed, 21 Jan 2009 22:48:49 +0100 (CET) > From: Mail Delivery System > Subject: Undelivered Mail Returned to Sender > To: [email protected] > 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 > > : 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; [email protected] > Arrival-Date: Wed, 21 Jan 2009 22:48:48 +0100 (CET) > > Final-Recipient: rfc822; [email protected] > Original-Recipient: rfc822;[email protected] > 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 ([email protected]) <*> 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 [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] Questions/comments on documentation formatting
On Wed, Jan 21, 2009 at 13:53, Georg Brandl 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 [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] Where is Fred Drake?
On Wed, Jan 21, 2009 at 6:39 PM, Aahz wrote: > Mail to [email protected] is bouncing; I don't know whether it's a > temporary failure. Does anyone have another address for him? /me channels Fred: Use [email protected] until the acm.org account is back up. -- Benji York ___ 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 3142: Add a "while" clause to generator expressions
On 21Jan2009 14:02, Tres Seaver 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 DoD#743 http://www.cskk.ezoshosting.com/cs/ Why doesn't DOS ever say EXCELLENT command or filename? ___ 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 8 and constants
Yes, that's what I commonly see. On Wed, Jan 21, 2009 at 6:42 PM, Benjamin Peterson wrote: > On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum wrote: >> On Wed, Jan 21, 2009 at 10:00 AM, Aahz 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 [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 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 [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 8 and constants
>> On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum wrote: >>> On Wed, Jan 21, 2009 at 10:00 AM, Aahz 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 [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 8 and constants
On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum wrote: > On Wed, Jan 21, 2009 at 10:00 AM, Aahz 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 [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 8 and constants
On Wed, Jan 21, 2009, Benjamin Peterson wrote: >>> On Wed, Jan 21, 2009 at 12:48 PM, Guido van Rossum wrote: On Wed, Jan 21, 2009 at 10:00 AM, Aahz 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 ([email protected]) <*> 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 [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 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 in [while [ | not ]: > > > The predicate would be tested after an is taken from > and before execution of the . If the predicate evaluates to > false, StopIteration would be raised. This construct would be > equivalent to: > > for in : > if [not | ]: break > > > 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 | [email protected] | Brisbane, Australia --- ___ 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 3142: Add a "while" clause to generator expressions
Cameron Simpson wrote: > On 21Jan2009 14:02, Tres Seaver 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 | [email protected] | Brisbane, Australia --- ___ 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 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 | [email protected] | Brisbane, Australia --- ___ 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
