Re: [Python-Dev] Wishlist: dowhile
Jp Calderone writes: > Anything can be a for loop. > > for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): > f2.write(chunk) Raymond responds: > It would be nice to have this encapsulated in a file method: > > for chunk in f1.iterblocks(CHUNK_SIZE): > f2.write(chunk) What ever happened to "Not every 3 line function needs to be a builtin"? It's a common pattern. It's easy to do. Where's the problem? -- Michael Chermside ___ 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] Wishlist: dowhile
On Jun 14, 2005, at 2:25 AM, Raymond Hettinger wrote: >> def readby(inp, blocksize=1024): >> while True: >> data = inp.read(blocksize) >> if not data: >> break >> yield data >> >> for data in readby(inp, blocksize): >> . . . >> > > readby() relies on the existence of a read() method for inp. > itertools work with generic iterators, not ones with a specific API. > Law of Demeter. islice depends on __getitem__. -bob ___ 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 343 - next steps
Phillip J. Eby wrote: > Ow. My head hurts. :) Seriously, though, wouldn't it make more sense > to put the 'with async_exceptions_blocked()' in the __init__ or > __enter__ of 'critical_resource'? Or am I still missing something? Heck, I *suggested* the trick, and still had to look at it a half dozen times, including frontways, and backways and upside down in order to satisfy myself that it actually addressed all the issues Guido and I had been talking about. Anyway, the kicker is that (in the rare cases where it matters), you want asynchronous exceptions blocked before EXPR gets evaluated, and then unblocked again after the try/finally has been entered, but before BLOCK starts evaluating. I believe the only real way to do that deterministically is to do the blocking and unblocking of asynchronous exceptions inline - when the asynchronous exception occurs, either the critical resource hasn't been acquired yet, or we are inside a try/finally that will ensure its release. Trying to push the blocking/unblocking inside a template like safe_acquisition actually results in the loss of that determinism, since it may be the case that safe_acquisition itself is not finalised properly (the asynchronous exception goes off prior to entry of the relevant try/finally block). However, the generator object's __del__ method will clean things up eventually. Anyway, the main point is that with statements won't make any more guarantees about this than try/finally statements do - but they do provide the tool to deal with it reasonably cleanly when it matters (most of the time the asynchronous error will indicate program shutdown, and the remote possibility of misbehaviour won't really matter in practice). Cheers, Nick. P.S. I've included this trick as part of the Wiki discussion, meaning my last PEP 343 question has been well and truly dealt with. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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
[Python-Dev] A bug in pyconfig.h under Linux?
Hi all, sorry for posting to this list, but I'm not even 100% sure this is a bug. If it is, I'll gladly post it to SF if you folks want it there. I use scipy a lot, and the weave.inline component in there allows dynamic inclusion of C/C++ code in Python sources. In particular, it supports Blitz++ array expressions for access to Numeric arrays. However, whenever I use blitz-based code, I get these annoying warnings: In file included from /usr/include/python2.3/Python.h:8, from sc_weave.cpp:5: /usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/os_defines.h:39, from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++config.h:35, from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/string:45, from /usr/lib/python2.3/site-packages/weave/blitz-20001213/blitz/blitz.h:153, from /usr/lib/python2.3/site-packages/weave/blitz-20001213/blitz/array-impl.h:154, from /usr/lib/python2.3/site-packages/weave/blitz-20001213/blitz/array.h:94, from sc_weave.cpp:4: /usr/include/features.h:150:1: warning: this is the location of the previous definition This is on a Fedora Core 3 box, using glibc-headers.i386 version 2.3.5. The source of the problem seems to be that in file /usr/include/python2.3/pyconfig.h, line 850, I have: /* Define to activate features from IEEE Stds 1003.1-2001 */ #define _POSIX_C_SOURCE 200112L But the system headers, in /usr/include/features.h, line 150 give: # define _POSIX_C_SOURCE199506L Hence the double-define. Now, I noticed that the system headers all use the following approach to defining these constants: # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE199506L etc. That is, they undef everything before defining their value. I applied the same change manually to pyconfig.h: /* Define to activate features from IEEE Stds 1003.1-2001 */ #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200112L and my spurious warnings went away. But I realize that pyconfig.h is auto-generated, so the right solution, if this is indeed a bug, has to be applied somewhere else, at the code generation source. I am unfortunately not familiar enough with Python's build system and the autoconf toolset to do that. Furthermore, I am not even 100% sure this is really a bug, though the spurious warning is very annoying. If this is indeed a bug, do you folks want it reported on SF as such? In that case, is this explanation enough/correct? Any advice would be much appreciated. Regards, Fernando. ___ 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] A bug in pyconfig.h under Linux?
Fernando Perez wrote: > sorry for posting to this list, but I'm not even 100% sure this is a bug. If > it > is, I'll gladly post it to SF if you folks want it there. This is not a bug. Most likely, sc_weave.cpp fails to meet the requirement documented in http://docs.python.org/api/includes.html "Warning: Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included. " If you follow this recommendation, this kind of error should not occur. 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] A bug in pyconfig.h under Linux?
"Martin v. Löwis" wrote: > Fernando Perez wrote: >> sorry for posting to this list, but I'm not even 100% sure this is a bug. >> If it is, I'll gladly post it to SF if you folks want it there. > > This is not a bug. Most likely, sc_weave.cpp fails to meet the > requirement documented in > > http://docs.python.org/api/includes.html > > "Warning: Since Python may define some pre-processor definitions which > affect the standard headers on some systems, you must include Python.h > before any standard headers are included. " Many thanks to Martin and Jeff Epler for the feedback, and sorry for the noise, the bug was in weave and not in pyconfig.h. I was able to fix scipy's weave to respect this constraint, which it didn't in the case of blitz-enhanced array handling code. Regards, f ___ 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] Wishlist: dowhile
[Bob] > islice depends on __getitem__. Incorrect. It uses the iterator protocol. ___ 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] Dynamic class inheritance && something else
Hi. My name is Veronica, I am a master student at UNAM. I am working on something related to Artificial Inteligence and I have been looking for the most appropriated programming language to implement my algorithms. I found python to be very close to what I need, but there are still a couple of details that I haven't been able to solve. First, (and most important) I would like to be able to dynamically modify the classes from which a class inherits. I haven't found any way to do it with the language as it is. If there is a way, any suggestion will be truly appreciated. If I had to modify the source code to achieve this, I hope that you could give me some hints; I have an idea of how something like this could be achieved but since I don't know deeply the python sourcode I could get lost. Second, since my program will be modifying classes during run time, I would like to have a way to write on a file the python code that would have defined the class with the functions and attributes as they were left, just as if it had been writen like that at the very begining. I need it to be python code because I will be using that latter. Maybe I will have to solve this second problem by myself but I just wrote in case anybody had a good idea. Thank you very much for your help. Vero La sociedad es inherentemente democrática: la mayoría decide si pensar por si misma o si dejar que alguien más les diga qué pensar. http://mx.geocities.com/aqua_azul_2000/ Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx ___ 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] Dynamic class inheritance && something else
On Tue, Jun 14, 2005, Vero wrote: > > Hi. My name is Veronica, I am a master student at UNAM. I am working > on something related to Artificial Inteligence and I have been looking > for the most appropriated programming language to implement my > algorithms. I found python to be very close to what I need, but there > are still a couple of details that I haven't been able to solve. Hi Veronica, python-dev is for future development of Python; for questions about using Python, please go to comp.lang.python. Thanks. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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] Dynamic class inheritance && something else
On 6/14/05, Vero <[EMAIL PROTECTED]> wrote: > Hi. My name is Veronica, I am a master student at UNAM. I am working on > something related to Artificial Inteligence and I have been looking for the > most appropriated programming language to implement my algorithms. I found > python to be very close to what I need, but there are still a couple of > details that I haven't been able to solve. > > First, (and most important) I would like to be able to dynamically modify > the classes from which a class inherits. I haven't found any way to do it > with the language as it is. If there is a way, any suggestion will be truly > appreciated. If I had to modify the source code to achieve this, I hope > that you could give me some hints; I have an idea of how something like this > could be achieved but since I don't know deeply the python sourcode I could > get lost. I wonder if assignment to __class__ (for instances) or to __bases__ (for classes) is what you are looking for? >>> class C: def foo(self): print "foo" >>> class D: def foo(self): print "D.foo" >>> x = C() >>> x.__class__ = D >>> x.foo() D.foo >>> x.__class__ = C >>> x.foo() foo >>> > Second, since my program will be modifying classes during run time, I would > like to have a way to write on a file the python code that would have > defined the class with the functions and attributes as they were left, just > as if it had been writen like that at the very begining. I need it to be > python code because I will be using that latter. Maybe I will have to solve > this second problem by myself but I just wrote in case anybody had a good > idea. That one's not so easy; there's no standard solution for this problem. I recommend that you follow Aahz' suggestion of asking on c.l.py instead. -- --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] Wishlist: dowhile
> > do: > > > > until > > > > Written like this it is not very obvious that the 'unil' is part of > > the do-until suite. I also imagine it to be difficult to parse and it > > breaks the rule that suites end when there is a dedentation. So, IMHO > > using an indented 'until' is the least evil of a number of evils. > > Not difficult to parse at all, nor un-Pythonic. Multi-part blocks > abound in Python: if / elif / else, try / finally, etc. Oh. I had the impression that the reason do-while's (or do-until's which I like more) wasn't implemented in the language was because it was impossible to find an acceptable looking syntax. > > Yes, but grepping the stdlib produces over 300 hits for "while 1:" and > > "while True:" combined. Some of those a "if : break" in the > > middle and some would be better written as generators, but lots of > > them would be rewritten as do-while's. So I think there is more than > > enough use cases for syntactic sugar for do-while loops. > > The PEP 315 solution looks much better than an "until" that isn't what > it looks like. What do you mean by that? The proposed until would work exactly like it do in languages that support until loops. I'm also reasonably happy with PEP 315, except that it seems to force you to end it with a pass if the condition is last in the loop. But is discussing do-while's beating a dead horse or is there a possibility that do-while's will someday make it into the language? -- mvh Björn ___ 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] Wishlist: dowhile
Nick Coghlan wrote: > With PEP 315, a do-while loop would look like: > >do: > >while : >pass > > But then, I'm reasonably happy with the 'break out of an infinite > loop' approach, so *shrug*. From Programming Languages 101 I remember this construct in Algol 68. It was then claimed to be *the* universal loop construct. If that is true __and__ it is easy to implement, I'd say +INF for PEP 315. --eric ___ 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] Wishlist: dowhile
On 6/14/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> Oh. I had the impression that the reason do-while's (or do-until's
> which I like more) wasn't implemented in the language was because it
> was impossible to find an acceptable looking syntax.
No, just because it's fairly redundant.
> > > Yes, but grepping the stdlib produces over 300 hits for "while 1:" and
> > > "while True:" combined. Some of those a "if : break" in the
> > > middle and some would be better written as generators, but lots of
> > > them would be rewritten as do-while's. So I think there is more than
> > > enough use cases for syntactic sugar for do-while loops.
> >
> > The PEP 315 solution looks much better than an "until" that isn't what
> > it looks like.
>
> What do you mean by that? The proposed until would work exactly like
> it do in languages that support until loops. I'm also reasonably happy
> with PEP 315, except that it seems to force you to end it with a pass
> if the condition is last in the loop. But is discussing do-while's
> beating a dead horse or is there a possibility that do-while's will
> someday make it into the language?
You are proposing 'until' that is indented. That is unlike any other
language. Translating this to curly-braces style, you're proposing
this:
do {
...body...
until (x <= 0);
}
I find this bizarre, not " exactly like it do [sic] in languages that
support until loops."
--
--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] Wishlist: dowhile
> > With PEP 315, a do-while loop would look like: > > > >do: > > > >while : > >pass > > But then, I'm reasonably happy with the 'break out of an infinite > > loop' approach, so *shrug*. > From Programming Languages 101 I remember this construct in Algol 68. > It was then claimed to be *the* universal loop construct. If that is > true __and__ it is easy to implement, I'd say +INF for PEP 315. I believe that Algol 68 loops looked like the following (in somewhat more Python-like terms): [for [from ] [step ] to ] [while ] do od where either "for" or "while" had to be present. Note that in Algol 68, the value of a "suite" (which I think they called a "serial clause") is the value of the last expression in it. ___ 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] Wishlist: dowhile
On 6/14/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote: > From Programming Languages 101 I remember this construct in Algol 68. > It was then claimed to be *the* universal loop construct. If that is > true __and__ it is easy to implement, I'd say +INF for PEP 315. It's true, but this both dates you (A68 has been dead for several decades) and locates you: it was said that A68's popularity was inversely proportional to (the square of?) the distance from Amsterdam. It also dates and locates me. :-) -- --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] Wishlist: dowhile
Guido van Rossum wrote: > On 6/14/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote: >> From Programming Languages 101 I remember this construct in Algol 68. >> It was then claimed to be *the* universal loop construct. If that is >> true __and__ it is easy to implement, I'd say +INF for PEP 315. > > It's true, but this both dates you (A68 has been dead for several > decades) and locates you: it was said that A68's popularity was > inversely proportional to (the square of?) the distance from > Amsterdam. It also dates and locates me. :-) Lucky me ;-) ___ 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] Compiling Python with Intel compiler?
Intel has a free (as in beer) C compiler for Linux. A friend of mine is involved in its production and marketing. He would like to see how "his" compiler does on Python -- does it work at all, and is there a speedup? I promised him I'd look into this, but between PEPs and my day job I don't seem to have the time, so now I'm making up on my promise by trying to delegate... The compiler is here: http://www.intel.com/software/products/compilers/clin/index.htm On the right is a link to a "Free Non-Commercial Download". That's all I know. I think that if someone puts some time in this, they should get a free Intel T-shirt. -- --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] Compiling Python with Intel compiler?
Guido van Rossum wrote: > Intel has a free (as in beer) C compiler for Linux. A friend of mine > is involved in its production and marketing. He would like to see how > "his" compiler does on Python -- does it work at all, and is there a > speedup? There is a bug report on this compiler: python.org/sf/1162001 There is also a patch, python.org/sf/1162023 which works around the bug. I don't like the work-around, because it assumes that the compiler binary is called "icc", however, it might be called just "cc" on some installations. With that issue resolved, the compiler apparently can build Python. However, the resulting interpreter doesn't work for some people: http://mail.python.org/pipermail/python-list/2005-March/270672.html This issue apparently only exists if you use both -O3 and -xN; if you omit one of them, it builds fine. I suspect a compiler bug. As for performance, Perky compared ICC (unspecified version) with gcc 2.95 on FreeBSD 4.5: http://groups-beta.google.com/group/sol.lists.freebsd.ports/msg/90a736b7097d9b05 At that point, the then-current version of ICC produced faster code than the then-current version of gcc (this was in 2002). In Dec 2004, Mark Asbach did the same thing with ICC 8 vs. gcc 3.3.4, on Linux: http://groups-beta.google.com/group/comp.lang.python/msg/a4af997f8f95592e?hl=en He reported a small speedup. I couldn't find anything on Python and ICC V9. 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 338 open ( -1) / 2861 closed ( +4) / 3199 total ( +3) Bugs: 909 open ( +1) / 5047 closed (+11) / 5956 total (+12) RFE : 188 open ( -1) / 170 closed ( +2) / 358 total ( +1) New / Reopened Patches __ byteorder issue in PyMac_GetOSType (2005-06-10) http://python.org/sf/1218421 opened by Ronald Oussoren os.kill on windows (2005-06-14) http://python.org/sf/1220212 opened by Miki Tebeka _csv.c leaks when dialect creation fails (2005-06-14) http://python.org/sf/1220242 opened by Michael Hudson Patches Closed __ in IDLE, assume new text files are python source by default (2005-05-06) http://python.org/sf/1196895 closed by kbk Add const specifier to PySpam_System prototype (2005-04-21) http://python.org/sf/1187396 closed by birkenfeld Newline in error output of py_compile.compile (2005-03-26) http://python.org/sf/1171150 closed by birkenfeld trivial bug in error message text (2005-05-06) http://python.org/sf/1196980 closed by kbk New / Reopened Bugs ___ email.Utils.py: "'" in RFC2231 header (2005-06-10) http://python.org/sf/1218081 opened by Tokio Kikuchi inspect.getsource doesn't update when a module is reloaded (2005-06-10) http://python.org/sf/1218234 opened by Björn Lindqvist Parser chokes on big files (2005-06-11) CLOSED http://python.org/sf/1218930 opened by Alexander Schremmer 'Expression' AST Node not documented (2005-06-12) http://python.org/sf/1219273 opened by Martin Miller copy.py typo (2005-06-13) CLOSED http://python.org/sf/1219342 opened by Ori Avtalion copy.py typo (2005-06-13) CLOSED http://python.org/sf/1219361 opened by Ori Avtalion small output bug (2005-06-12) CLOSED http://python.org/sf/1219448 opened by Alex Levchuk Need locale arg to strftime() (2005-06-13) http://python.org/sf/1219840 opened by Wilfredo Sanchez misdocumented argument range for curses.pair_content (2005-06-13) CLOSED http://python.org/sf/1219862 opened by dcrosta tp_richcompare documentation wrong and incomplete (2005-06-13) http://python.org/sf/1219903 opened by Barry A. Warsaw subprocess call() helper should close stdin if PIPE (2005-06-14) http://python.org/sf/1220113 opened by Stuart Bishop Re-importing embedded thread dumps core (2005-06-14) http://python.org/sf/1220756 opened by Jay T Miller Bugs Closed ___ Parser chokes on big files (2005-06-11) http://python.org/sf/1218930 closed by doerwalter color highlighting not working on EDIT windows (2003-09-04) http://python.org/sf/800432 closed by kbk No syntax hilite on new file until saved as *.py (2003-07-21) http://python.org/sf/775012 closed by kbk copy.py typo (2005-06-12) http://python.org/sf/1219342 closed by rhettinger copy.py typo (2005-06-12) http://python.org/sf/1219361 closed by rhettinger small output bug (2005-06-12) http://python.org/sf/1219448 closed by rhettinger misdocumented argument range for curses.pair_content (2005-06-13) http://python.org/sf/1219862 closed by akuchling lax error-checking in new-in-2.4 marshal stuff (2005-04-11) http://python.org/sf/1180997 closed by mwh String and list methods documentation deeply hidden (2005-06-06) http://python.org/sf/1215887 closed by rhettinger Queue.qsize() better info about unreliability (2005-06-02) http://python.org/sf/1213475 closed by rhettinger weakref cannot handle bound methods (in contrast to docu) (2005-05-22) http://python.org/sf/1206537 closed by rhettinger New / Reopened RFE __ Create a fat build on darwin (2005-06-10) http://python.org/sf/1218333 opened by Ronald Oussoren RFE Closed __ Make bisect.* functions accept an optional compare function (2005-04-18) http://python.org/sf/1185383 closed by rhettinger sets needs an 'arbitrary element' method (2005-05-31) http://python.org/sf/1212091 closed by rhettinger ___ 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
