Mailman 3 March 2005 - Python-Dev

Python 2.4 | 7.3 The for statement
by Juan Carlos Rodrigo Garcia 20 Mar '05

20 Mar '05

Hi My name is Juan Carlos Rodrigo, and I love Python. It is the most impressive and usefull language that I have ever seen. I am studing, at http://www.uoc.edu, an Information Technology Postgraduate. And I have programmed some REXX applications in my past Jobs (So I love python, no more ENDS). This is my Graduate final project http://ip.xpyro.com made in mod_python. I love mod_python too. Please don't crash my AMD making queries. :| --------8<--------8<--------8<--------8<--------8<--------8<-------- Python 2.4 | 7.3 The for statement: ----------------------------------- for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite] New for statement: ------------------ for_stmt ::= "for" target_list "in" expression_list [ "and" expression ] ":" suite ["else" ":" suite] ** If the expression evaluates to False before entering the for, jump else. ** If the expression is evaluated to False after the first iteration, break. So ¿What we can do with this new for?, and ¿It is going to avoid line exceed?: "My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed." [1] It is easier if we see it beforehand: ------------------------------------- leave = False alist = [1,2,3,3,4,5,6,7,8,9] for item in alist and not leave: if item is 1: leave = True Avoiding code exceed: --------------------- a = 1 b = 2 c = 3 alist = [1,2,3,4,5,6,7,8,9] for item in alist and a < 2 and b < 3 and c < 4: if item == 3: a += 1 if item == 2: b += 1 if item == 1: c += 1 print "%d %d %d" % (a,b,c) # three lines off (25% less on breaks) Other features and the else: ---------------------------- alist = [1,2,3] enter = False if list[0] == 4: enter = True for item in alist and enter: print item else: print "No account" The real problem: ----------------- "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended." [1] Ok, it's not recommended, at large, but Python should make it possible, and then the people will choose. [1] Go To Statement Considered Harmful Edsger W. Dijkstra http://www.acm.org/classics/oct95/ PD: Your work is impressive, thanks. -- Juan Carlos Rodrigo Garcia. jrodrigog(a)gmail.com

5 4

Re: [Python-Dev] Python 2.4 | 7.3 The for statement
by Nick Coghlan 20 Mar '05

20 Mar '05

Juan Carlos Rodrigo wrote: >>Interesting idea, but not really needed given the existence of the break statement: > > > Goto = break > I'm not interested. All non-sequential control structures are merely constrained ways of using goto (the underlying machine code will devolve into conditional and unconditional branches and jumps - i.e. goto's). 'break' is a highly constrained form of goto and a fundamental part of structured programming (as is 'continue') - each is limited to a local effect on the loop that contains them. This is a far cry from the ability to jump to an arbitrary label that gives goto its bad reputation. I used to share your sentiment regarding break and continue - experience (especially Python experience) has convinced me otherwise. Python embraces the concept of breaking out of a loop to the point that it even has an 'else' clause on loop structures that is executed only if the loop is exited naturally rather than via a break statement. Regardless of whether you personally choose to use break and continue, the existence of those statements is the main reason that the addition of a flag condition to for loops is highly unlikely. If you want to terminate a for loop before the iterable is exhausted, the recommended solution is to use a break statement. To illustrate the point about all control structures being gotos, even a simple do-nothing for loop results in a JUMP_ABSOLUTE (goto!) in the generated bytecode: Py> def f(): ... for item in range(10): ... pass ... Py> import dis Py> dis.dis(f) 2 0 SETUP_LOOP 20 (to 23) 3 LOAD_GLOBAL 0 (range) 6 LOAD_CONST 1 (10) 9 CALL_FUNCTION 1 12 GET_ITER >> 13 FOR_ITER 6 (to 22) 16 STORE_FAST 0 (item) 3 19 JUMP_ABSOLUTE 13 >> 22 POP_BLOCK >> 23 LOAD_CONST 0 (None) 26 RETURN_VALUE Cheers, Nick. -- Nick Coghlan | ncoghlan(a)email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net

1 0

Python 2.4 won the "Jolt productivity award" last night
by Guido van Rossum 19 Mar '05

19 Mar '05

Python 2.4 won the "Jolt productivity award" last night. That's the runner-up award; in our category, languages and development tools, the Jolt (the category winner) went to Eclipse 3.0; the other runners-up were IntelliJ and RealBasic (no comment :-). Like usually, open source projects got several awards; both Subversion and Hibernate (an open source Java persistency library) got Jolts. Maybe from now on we should add "award-winning" whenever we refer to Python 2.4. If someone can find out the website where the results are summarized (I'm sure there is one but I'm too lazy to Google). -- --Guido van Rossum (home page: http://www.python.org/~guido/)

4 4

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 19 Mar '05

19 Mar '05

Patch / Bug Summary ___________________ Patches : 286 open ( +7) / 2801 closed ( +4) / 3087 total (+11) Bugs : 870 open (+19) / 4867 closed (+14) / 5737 total (+33) RFE : 175 open ( +2) / 150 closed ( +0) / 325 total ( +2) New / Reopened Patches ______________________ inspect.py fix for bug #1143895 (2005-03-09) CLOSED http://python.org/sf/1159931 reopened by arigo inspect.py fix for bug #1143895 (2005-03-09) CLOSED http://python.org/sf/1159931 opened by Simon Percivall use ReleaseItanium configuration for zlib IA64 build (2005-03-09) http://python.org/sf/1160164 opened by Trent Mick skip winsound for Windows/IA64 build (2005-03-09) http://python.org/sf/1160169 opened by Trent Mick Add method to function objects to simplify decoration (2005-03-12) http://python.org/sf/1161819 opened by Nick Coghlan python-config (2005-03-12) http://python.org/sf/1161914 opened by Andre Jonsson don't add -OPT:Olimit=0 for icc (2005-03-12) http://python.org/sf/1162023 opened by Michael Hoffman Heap class for heapq module (2005-03-13) http://python.org/sf/1162363 opened by Stefan Behnel EditorWindow's title with non-ASCII chars. (2005-03-14) http://python.org/sf/1162825 opened by SUZUKI Hisao _POSIX_SEMAPHORES checked incorrectly (2005-03-14) CLOSED http://python.org/sf/1163249 opened by Bob Ippolito the quotes page on the Web site links to something broken (2005-03-14) http://python.org/sf/1163314 opened by Shannon -jj Behrens small sanity checks for user-defined mros (2005-03-15) http://python.org/sf/1163731 opened by Michael Hudson Using size_t where appropriate (2005-03-18) http://python.org/sf/1166195 opened by Martin v. Löwis Patches Closed ______________ inspect.py fix for bug #1143895 (2005-03-09) http://python.org/sf/1159931 closed by jlgijsbers inspect.py fix for bug #1143895 (2005-03-09) http://python.org/sf/1159931 closed by jlgijsbers Syntax for iterator slicing, concatenation and repetition (2005-01-24) http://python.org/sf/1108272 closed by ncoghlan fix for a deadlock in the logging module (2005-03-07) http://python.org/sf/1158052 closed by vsajip _POSIX_SEMAPHORES checked incorrectly (2005-03-15) http://python.org/sf/1163249 closed by anthonybaxter New / Reopened Bugs ___________________ Setup file needs entries for collections, itertools, strop (2005-03-09) CLOSED http://python.org/sf/1160187 opened by Niraj Bajpai urllib2 post error when using httpproxy (2005-03-10) http://python.org/sf/1160328 opened by small tiger digit-only tag values are mishandled in Tkinter (2005-03-09) http://python.org/sf/1160383 opened by Ilya Sandler Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly (2005-03-10) CLOSED http://python.org/sf/1160534 opened by Richard Brooksby Can't build Zope on Windows w/ 2.4.1c1 (2005-03-10) CLOSED http://python.org/sf/1160802 opened by Tim Peters Neverending warnings from asyncore (2005-03-11) http://python.org/sf/1161031 opened by Tony Meyer Install problem 2.4.1rc1 on Win98 (2005-03-11) CLOSED http://python.org/sf/1161187 opened by Spider Incorrect return value in gc docs (2005-03-11) CLOSED http://python.org/sf/1161476 opened by Aravind Minor error in section 3.2 (2005-03-11) http://python.org/sf/1161595 opened by Jeremy Barbay configure incorrectly adds -OPT:Olimit=0 for icc (2005-03-12) http://python.org/sf/1162001 opened by Michael Hoffman inspect.getmembers() breaks sometimes (2005-03-12) http://python.org/sf/1162154 opened by Doug Quale subprocess.Popen with copious output hangs (2005-03-13) http://python.org/sf/1162428 opened by neuhauser Parsing failures in parsedate_tz (2005-03-13) http://python.org/sf/1162477 opened by TH Unable to Install Python 2.4.1rc1 on windows XP SP2 (2005-03-13) http://python.org/sf/1162677 opened by Sergio Correia typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) http://python.org/sf/1162912 opened by Stefan Behnel IDNA StreamReader broken (2005-03-14) http://python.org/sf/1163178 opened by Walter Dörwald Syntax error on large file with MBCS encoding (2005-03-14) http://python.org/sf/1163244 opened by Tim N. van der Leeuw "special" decimals aren't hashable (2005-03-14) CLOSED http://python.org/sf/1163325 opened by Marien Zwart correct/clarify documentation for super (2005-03-14) http://python.org/sf/1163367 opened by Steven Bethard uncaught AttributeError deep in urllib (2005-03-14) http://python.org/sf/1163401 opened by K Lars Lohn Sub threads execute in restricted mode (2005-03-15) http://python.org/sf/1163563 opened by anothermax subprocess pipe fails under Emacs (2005-03-15) http://python.org/sf/1163759 opened by Anders J. Munch super(...).__new__( ... ) behaves "unexpected" (2005-03-16) http://python.org/sf/1164631 opened by Dirk Brenckmann UserDict is not iterable (2005-03-16) CLOSED http://python.org/sf/1164726 opened by Kent Johnson Tkdnd.py crashes due to read-only attributes (2005-03-16) http://python.org/sf/1164742 opened by tynods xmlrpclib.DateTime.decode() should stringify argument (2005-03-16) http://python.org/sf/1164912 opened by Allan Saddi logging.basicConfig creates phantom handler (2005-03-16) CLOSED http://python.org/sf/1164953 opened by logistix Property access with decorator makes interpreter crash (2005-03-17) http://python.org/sf/1165306 opened by Remy Blank KeyboardInterrupt causes segmentation fault with threads (2005-03-17) http://python.org/sf/1165761 opened by Jeff Stearns SSL_pending is not used (2005-03-18) http://python.org/sf/1166206 opened by hahahhah missing sequence tests - pull from deque (2005-03-18) http://python.org/sf/1166274 opened by Jim Jewett No os.spawn*p* on Windows (2005-03-19) http://python.org/sf/1166378 opened by Chris Palmer Bugs Closed ___________ inspect.getsource() breakage in 2.4 (2005-02-18) http://python.org/sf/1143895 closed by jlgijsbers Setup file needs entries for collections, itertools, strop (2005-03-09) http://python.org/sf/1160187 closed by rhettinger unixccompiler.py should deal with env in linker (2005-03-07) http://python.org/sf/1158005 closed by jackjansen Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly (2005-03-10) http://python.org/sf/1160534 closed by loewis Can't build Zope on Windows w/ 2.4.1c1 (2005-03-10) http://python.org/sf/1160802 closed by tim_one test_socket fails when not connected (2003-03-19) http://python.org/sf/706450 closed by bcannon Install problem 2.4.1rc1 on Win98 (2005-03-11) http://python.org/sf/1161187 closed by loewis Incorrect return value in gc docs (2005-03-11) http://python.org/sf/1161476 closed by iamfenris [2.4 regression] seeking in codecs.reader broken (2005-03-03) http://python.org/sf/1156259 closed by doerwalter configure and gmake fail in openbsd 3.5 i386 (2004-06-24) http://python.org/sf/978632 closed by loewis "special" decimals aren't hashable (2005-03-14) http://python.org/sf/1163325 closed by rhettinger Warnings in Python.h with gcc 4.0.0 (2005-01-20) http://python.org/sf/1105699 closed by loewis UserDict is not iterable (2005-03-16) http://python.org/sf/1164726 closed by rhettinger logging.basicConfig creates phantom handler (2005-03-17) http://python.org/sf/1164953 closed by vsajip New / Reopened RFE __________________ expm1 and log1p (2005-03-14) http://python.org/sf/1163139 opened by Keith Briggs ConfigParser alternative key-value delimitier (2005-03-17) http://python.org/sf/1165404 opened by Sergey Dorofeev

1 0

thread semantics for file objects
by Jeremy Hylton 19 Mar '05

19 Mar '05

Are the thread semantics for file objecst documented anywhere? I don't see anything in the library manual, which is where I expected to find it. It looks like read and write are atomic by virtue of fread and fwrite being atomic. I'm less sure what guarantees, if any, the other methods attempt to provide. For example, it looks like concurrent calls to writelines() will interleave entire lines, but not parts of lines. Concurrent calls to readlines() provide insane results, but I don't know if that's a bug or a feature. Specifically, if your file has a line that is longer than the internal buffer size SMALLCHUNK you're likely to get parts of that line chopped up into different lines in the resulting return values. If we can come up with intended semantics, I'd be willing to prepare a patch for the documentation. Jeremy

7 16

__metaclass__ problem
by Dirk Brenckmann 19 Mar '05

19 Mar '05

Hi there, first of all I'd like to introduce myself, because I'm new to this list. If I did wrong to post here, please be patient... The reason for my posting is my previous work with __metaclass__ and advice.py, which is nice to use. While working with __metaclass__ I found situations, where I could not explain the resulting output/behaviour of type.__new__ (super(...,...).__new__) using the available documentation. This is why I've been posting bug no. 1164631 - super(...).__new__( ... ) behaves "unexpected". After having checked the C code of 'typeobject.c', I think I might explain the (undocumented) behaviour now (I've been adding a comment to bug no. 1164631). It is - in short - the following: Lines 1602 to 1626 of 'typeobject.c' decide the "winning" metaclass within any class hierarchy. The effekt I noticed - and still consider to be a bug - is introduced in lines 1611 to 1614: The metaclass of the current class will always be the type of class which is at most subclassed from the metatype previously named as "winner". In consequence a programmer only is in control of the "metaclass" of his class, if he decides it to be a subtype of all former metaclasses he used in his class hierarchy, or if he uses the same metaclass as the superclass does. The reasons, why I consider this a bug is: 1. This feature is undocumented. If there is a documentation of it, i might not have found it - or maybe it was not detailed enough to make a programmer (like me: just starting with metaclasses) understand that point. In either cases it would be great to complete the documentation. 2. The class code using __metaclass__, produced by a programmer sets clear directives for the way the resulting Product (the class) has to be and/or to behave. If instead a product even might behave in a completely other way, because it just intends to, this either is a M$ Product ;-) or a bug. 3. If the intention is fixed by a specification, the bug is not the products/programs behaviour then. Instead the bug is a missing Exception, which should inform the programmer of a programming error which violates the specifications. E.g.: TypeError( "__metaclass__ is not of the expected type." ) (or whatever...) 4. Apart the points 1 to 3 and without knowledge of the discussions you probably had while developing this __metaclass__ thing, I'd call it a pitty, if using supertypes of metaclasses as metaclass in a subtype of a class is prohibited. This would make the whole thing somehow incomplete, because it would result in the need of a programmer to know, all metaclasses that have been used by all classes down the mro to 'object'. ...ok - these are my thoughts to what I called the "__metaclass problem" in the subject of this mail. Of course, I'm not into python as long as you are, so: 1. I might have tried something completely stupid 2. I did not take into account the discussions you already might have had about that. Above all I'm not a native english speaker... ;-) ... please don't flame :-) Any feedback (or bugfixes? :-) welcome. Dirk Brenckmann -- "Happy ProMail" bis 24. M�rz: http://www.gmx.net/de/go/promail Zum 6. Geburtstag gibt's GMX ProMail jetzt 66 Tage kostenlos!

3 4

RELEASED Python 2.4.1, release candidate 1
by Anthony Baxter 18 Mar '05

18 Mar '05

On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (release candidate 1). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Assuming no major problems crop up, a final release of Python 2.4.1 will follow in about a week's time. For more information on Python 2.4.1, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.1/ Highlights of this new release include: - Bug fixes. According to the release notes, several dozen bugs have been fixed, including a fix for the SimpleXMLRPCServer security issue (PSF-2005-001). Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

8 19

Re: [Python-checkins] python/dist/src/Doc/lib libcsv.tex, 1.18, 1.19
by Walter Dörwald 18 Mar '05

18 Mar '05

montanaro(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Doc/lib > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22325 > > Modified Files: > libcsv.tex > Log Message: > add UnicodeReader and UnicodeWriter example classes > > [....] > +The \module{csv} module doesn't directly support reading and writing > +Unicode, but it is 8-bit clean save for some problems with \ASCII{} NUL > +characters, so you can write classes that handle the encoding and decoding > +for you as long as you avoid encodings like utf-16 that use NULs. The problem is more the fact that UTF-16 would require a stateful codec. For the UnicodeWriter IMHO the best solution would be to make the csv module unicode transparent (i.e. it simply calls the write method of the underlying stream). Then it should be possible to stack the streams like this: import csv, codecs w = cvs.writer(codecs.getwriter("utf-16")(open("foo.csv", "wb")) w.writerow([u"foo", u"bar")] If csv was implemented in Python this would be trivial. Bye, Walter Dörwald

1 0

RE: [Python-Dev] Faster Set.discard() method?
by Tony Meyer 18 Mar '05

18 Mar '05

>>> But the dict.pop method is about 12 times faster. Is this >>> worth doing? >> >> The 2.4 builtin set's discard function looks like it does >> roughly the same as the 2.3 sets.Set. Have you tried comparing >> a C version of your version with the 2.4 set to see if there are >> speedups there, too? > > Ah. I had forgotten it was builtin - I'd found the python > implementation and concluded the C implementation didn't make > it into 2.4 for some reason... 8-) > > Yes, the builtin set.discard() method is already faster than > dict.pop(). The C implementation has this code: """ if (PyDict_DelItem(so->data, item) == -1) { if (!PyErr_ExceptionMatches(PyExc_KeyError)) return NULL; PyErr_Clear(); } """ Which is more-or-less the same as the sets.Set version, right? What I was wondering was whether changing that C to a C version of your dict.pop() version would also result in speedups. Are Exceptions really that slow, even at the C level? =Tony.Meyer

3 2

RELEASED Python 2.4.1, release candidate 2
by Anthony Baxter 18 Mar '05

18 Mar '05

On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (release candidate 2). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Assuming no major problems crop up, a final release of Python 2.4.1 will be out around the 29th of March - straight after PyCon. For more information on Python 2.4.1, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.1 Highlights of this new release include: - Bug fixes. According to the release notes, several dozen bugs have been fixed, including a fix for the SimpleXMLRPCServer security issue (PSF-2005-001). - A handful other bugs discovered in the first release candidate have been fixed in this version. Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

1 0