Mailman 3 September 2005 - Python-Dev

Re: [Python-Dev] Adding a conditional expression in Py3.0
by Robert Brewer 30 Sep '05

30 Sep '05

Guido: > Now you've pushed me over the edge. I've made up my mind > now, "X if C else Y" it will be. I hope to find time to > implement it in Python 2.5. Steve Holden: > Not before time, either. If this ends the discussion then > I'll consider I've done everyone a favour. Sometimes no > decision is worse than the wrong decision ;-). Exactly how I felt about bringing the decorator decision to a close. ;) Congratulations to you both! Robert Brewer System Architect Amor Ministries fumanchu(a)amor.org

1 0

"and" and "or" operators in Py3.0
by Raymond Hettinger 30 Sep '05

30 Sep '05

I propose that in Py3.0, the "and" and "or" operators be simplified to always return a Boolean value instead of returning the last evaluated argument. 1) The construct can be error-prone. When an error occurs it can be invisible to the person who wrote it. I got bitten in published code that had survived testing and code review: def real(self): 'Return a vector with the real part of each input element' # do not convert integer inputs to floats return self.map(lambda z: type(z)==types.ComplexType and z.real or z) The code fails silently when z is (0+4i). It took a good while to trace down a user reported error (when Matlab results disagreed with my matrix module results) and determine that the real() method contained an error. Even when traced down, I found it hard to see the error in the code. Now that I know what to look for, it has not happened again, but I do always have to stare hard at any "and/or" group to mentally verify each case. 2) When going back and forth between languages, it is easy to forget that only Python returns something other than a boolean. 3) Even when it isn't being used, the possibility of non-boolean return value complicates the bytecode and parser. To allow for "and/or", the conditional opcodes leave the tested value on the stack. In most cases both branches go directly to a POP_TOP instruction. Since the POP_TOP shouldn't be executed twice, the body of the positive branch has to close with a jump over the other branch even when it is empty. For instance, the simplest case: if a: b compiles to: 1 0 LOAD_NAME 0 (a) 3 JUMP_IF_FALSE 8 (to 14) 6 POP_TOP 2 7 LOAD_NAME 1 (b) 10 POP_TOP 11 JUMP_FORWARD 1 (to 15) >> 14 POP_TOP >> 15 LOAD_CONST 0 (None) 18 RETURN_VALUE this could be simpler and faster: 1 0 LOAD_NAME 0 (a) 3 JUMP_IF_FALSE 8 (to 10) 2 6 LOAD_NAME 1 (b) 9 POP_TOP >> 10 LOAD_CONST 0 (None) 13 RETURN_VALUE Executive summary. Returning only Booleans reduces errors, makes the code easier to review, follows other language norms, and simplifies/speeds-up the generated code. Raymond P.S. Simplifying "and" and "or" may create a need to introduce a conditional operator but that is a discussion for another day.

36 80

linecache problem
by Thomas Heller 30 Sep '05

30 Sep '05

On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. Thomas

3 4

[PATCH][BUG] Segmentation Fault in xml.dom.minidom.parse
by Evan Jones 30 Sep '05

30 Sep '05

The following Python script causes Python 2.3, 2.4 and the latest CVS to crash with a Segmentation Fault: import xml.dom.minidom x = u'<?xml version="1.0"?>\n<fran\xe7ais>Comment \xe7a va ? Tr\xe8s bien ?</fran\xe7ais>' dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) ) print repr( dom.childNodes[0].localName ) The problem is that this XML document does not specify an encoding. In this case, minidom assumes that it is encoded in UTF-8. However, in fact it is encoded in Latin-1. My two line patch, in the SourceForge tracker at the URL below, causes this to raise a UnicodeDecodingError instead. http://sourceforge.net/tracker/index.php? func=detail&aid=1309009&group_id=5470&atid=305470 Any chance that someone wants to commit this tiny two line fix? This might be the kind of fix that might be elegible to be backported to Python 2.4 as well. It passes "make test" on both my Linux system and my Mac. I've also attached a patch that adds this test case to test_minidom.py. Thanks, Evan Jones -- Evan Jones http://evanjones.ca/

2 1

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 29 Sep '05

29 Sep '05

Patch / Bug Summary ___________________ Patches : 337 open ( +0) / 2947 closed ( +6) / 3284 total ( +6) Bugs : 912 open ( +4) / 5278 closed (+16) / 6190 total (+20) RFE : 195 open ( +1) / 187 closed ( +0) / 382 total ( +1) New / Reopened Patches ______________________ fix for distutils "upload" command (2005-09-23) http://python.org/sf/1299675 opened by Richard Jones xdrlib.py: pack_fstring() did not use null bytes for padding (2005-09-23) CLOSED http://python.org/sf/1300515 opened by Don Quijote desktop module (providing startfile as open, all platforms) (2005-09-23) http://python.org/sf/1301512 opened by Paul Boddie Update documentation for __builtins__ (2005-09-24) http://python.org/sf/1303595 opened by Collin Winter Strobe Timer for guis (2005-09-26) http://python.org/sf/1304895 opened by Brett Rosen pyexpat.c: Two line fix for decoding crash (2005-09-29) http://python.org/sf/1309009 opened by Evan Jones Patches Closed ______________ cjkcodecs does not initialize type pointer (2005-09-20) http://python.org/sf/1297028 closed by nnorwitz xdrlib.py: pack_fstring() did not use null bytes for padding (2005-09-23) http://python.org/sf/1300515 closed by birkenfeld vendor-packages directory. (2005-09-22) http://python.org/sf/1298835 closed by richburridge PyOS_InputHook inconsistency on Windows (2004-10-19) http://python.org/sf/1049855 closed by loewis FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) (2005-09-13) http://python.org/sf/1288833 closed by perky use LIST_APPEND opcode for X.append() method calls (2005-09-16) http://python.org/sf/1292625 closed by nnorwitz New / Reopened Bugs ___________________ A command history for the idle interactive shell (2005-09-24) http://python.org/sf/1302267 opened by Björn Lindqvist 2.4.1 windows MSI has no _socket (2005-09-24) http://python.org/sf/1302793 opened by IamPaul SSL-ed sockets don't close correct? (2004-06-24) http://python.org/sf/978833 reopened by kxroberto Bypassing __dict__ readonlyness (2005-09-24) http://python.org/sf/1303614 opened by Armin Rigo traceback on trying to load a file (2005-09-24) http://python.org/sf/1303673 opened by nanotube Extended slice bug (or feature?) (2005-09-25) CLOSED http://python.org/sf/1303928 reopened by mwh Extended slice bug (or feature?) (2005-09-25) CLOSED http://python.org/sf/1303928 opened by David M. Beazley 2.3.5 configure / make infinite loop (2005-09-25) http://python.org/sf/1304179 opened by Michael Schwartz windows unicode write is messing up the EOL. (2005-09-27) CLOSED http://python.org/sf/1305706 opened by Istvan Visegradi Syntax error in Python Library Reference, 6.1.4. Files ... (2005-09-27) CLOSED http://python.org/sf/1306043 opened by Alexander Schliep Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 (2005-09-27) CLOSED http://python.org/sf/1306211 opened by John Stone Add 64-bit Solaris 9 build instructions to README (2005-09-27) http://python.org/sf/1306248 opened by John Stone Python 2.4.2c1 fails to build on 64-bit Solaris 10 (2005-09-27) http://python.org/sf/1306253 opened by John Stone PyString_AsStringAndSize() return value documented wroing (2005-09-28) CLOSED http://python.org/sf/1306449 opened by Gregory Bond compile() converts "filename" parameter to StringType (2005-09-28) http://python.org/sf/1306484 opened by Vágvölgyi Attila Augmented assigment to mutable objects in tuples fail (2005-09-28) CLOSED http://python.org/sf/1306777 opened by Mattias Engdegård =, not = (2005-09-28) CLOSED http://python.org/sf/1307188 opened by Davide Andrea Datagram Socket Timeouts (2005-09-28) http://python.org/sf/1307357 opened by Tom Vrankar subprocess.Popen locks on Cygwin (2005-09-29) http://python.org/sf/1307798 opened by Jacek Poplawski PCbuild vcproj project files need a cleanup (2005-09-29) http://python.org/sf/1307806 opened by Adal Chiriliuc Unsatisfied symbols: _PyGILState_NoteThreadState (code) (2005-09-29) http://python.org/sf/1307978 opened by Goetz Isenmann Datagram Socket Timeouts (2005-09-29) http://python.org/sf/1308042 opened by Tom Vrankar Py_BuildValue (C/API): "K" format (2005-09-29) CLOSED http://python.org/sf/1308740 opened by Yair Chuchem Bugs Closed ___________ Incorrect return type for search() method (2005-09-20) http://python.org/sf/1297059 closed by nnorwitz build fails on Solaris 10 for Objects/complexobject.c (2005-09-22) http://python.org/sf/1299187 closed by nnorwitz test_ioctl fails (2003-07-26) http://python.org/sf/777867 closed by birkenfeld test_ioctl fails (2003-07-31) http://python.org/sf/780576 closed by birkenfeld subprocesss module retains older license header (2005-02-17) http://python.org/sf/1138653 closed by astrand inspect.getsource() misses single line blocks. (2005-09-20) http://python.org/sf/1295909 closed by arigo Extended slice bug (or feature?) (2005-09-25) http://python.org/sf/1303928 closed by birkenfeld Extended slice bug (or feature?) (2005-09-25) http://python.org/sf/1303928 closed by birkenfeld windows unicode write is messing up the EOL. (2005-09-27) http://python.org/sf/1305706 closed by visike Syntax error in Python Library Reference, 6.1.4. Files ... (2005-09-27) http://python.org/sf/1306043 closed by birkenfeld Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 (2005-09-27) http://python.org/sf/1306211 deleted by jestone PyString_AsStringAndSize() return value documented wrong (2005-09-28) http://python.org/sf/1306449 closed by birkenfeld Augmented assigment to mutable objects in tuples fail (2005-09-28) http://python.org/sf/1306777 closed by pje =, not = (2005-09-28) http://python.org/sf/1307188 closed by birkenfeld Py_BuildValue (C/API): "K" format (2005-09-29) http://python.org/sf/1308740 closed by birkenfeld "Howto RE" link is dead (2005-09-22) http://python.org/sf/1299051 closed by birkenfeld MemoryError in httplib (2005-09-20) http://python.org/sf/1296004 closed by birkenfeld shlex does not support unicode (2005-09-21) http://python.org/sf/1298120 closed by birkenfeld BaseHTTPServer to take host from cmdline? (2004-07-06) http://python.org/sf/985651 closed by birkenfeld New / Reopened RFE __________________ Please include pdb with windows distribution (2005-09-24) http://python.org/sf/1303434 opened by Lyle Thompson

1 0

Re: [Python-Dev] Conditional Expression Resolution
by Delaney, Timothy (Tim) 29 Sep '05

29 Sep '05

Guido van Rossum wrote: > Congratulations gracefully accepted. Whilst I'm not personally fond of the syntax, congratulations. Whilst I don't feel this is a big step in the evolution of the language, it shuts up a *very* frequently asked question (and opens up a new one ;) Tim Delaney

1 0

David Mertz on CA state e-voting panel
by Guido van Rossum 29 Sep '05

29 Sep '05

http://yro.slashdot.org/yro/05/09/28/1955256.shtml?tid=103&tid=17&tid=219 Congratulations David! (Don't have his email.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] Adding a conditional expression in Py3.0
by Michael Chermside 29 Sep '05

29 Sep '05

[ongoing discussion of conditional expressions] I waited until I had caught up on my reading before saying anything. Now I'll express my opinion in a single posting then keep quiet unless I actually find I have something novel to contribute (difficult in a topic that's been talked to death 3 or 4 times in the past few years). * I am STRONGLY in favor of introducing a conditional expression in some form. The use of the "and-or" trick is proof enough to me that there is a need for it. I can marshall other arguments also, but they appear unnecessary. * The syntax to use is a place where we need a BDFL decision. Make the decision and we'll all agree and move on. Any decision would be better than an eternity of re-discovering old ideas again and again. * I think the two best options are trueval if cond else falseval and if cond then trueval else falseval The first has brevity in it's favor, and "cleverness" which might be an advantage or disadvantage depending on your point of view. The second has order-of-arguments in its favor. In either case, wise programmers will use parenthesees when it aids clarity (imagine "v1 if c else v2 + v3"). Whether we require parenthesees when the parser could disambiguate on its own is really up to Guido. * I prefer the second form ("if cond then trueval else falseval") because it puzzles _nobody_ at the expense of being slightly more wordy and less clever. But that's just one person's opinion. Thanks Guido, for maintaining your patience in the face of this discussion. -- Michael Chermside

1 0

64-bit bytecode compatibility (was Re: [PEAK] ez_setup on 64-bit linux problem)
by Phillip J. Eby 29 Sep '05

29 Sep '05

At 09:49 AM 9/29/2005 -0400, Viren Shah wrote: >[I sent this earlier without being a subscriber and it was sent to the >moderation queue so I'm resending it after subscribing] > >Hi, > I'm running a 64-bit Fedora Core 3 with python 2.3.4. I'm trying to > install setuptools to use with Trac, and get the following error: > > [root@Mrdumpling ~]$ python ez_setup.py >Downloading >http://cheeseshop.python.org/packages/2.3/s/setuptools/setuptools-0.6a4-py2… >Traceback (most recent call last): > File "ez_setup.py", line 206, in ? > main(sys.argv[1:]) > File "ez_setup.py", line 141, in main > from setuptools.command.easy_install import main >OverflowError: signed integer is greater than maximum > > >I get the same type of error if I try installing setuptools manually. I >figure this has to do with the 64-bit nature of the OS and python, but not >being a python person, don't know what a workaround would be. > >Any ideas? Hm. It sounds like perhaps the 64-bit Python in question isn't able to read bytecode for Python from a 32-bit Python version. You'll need to download the setuptools source archive from PyPI and install it using "python setup.py install" instead. In the meantime, I'm going to inquire on Python-Dev about whether a 64-bit Python should be able to read 32-bit bytecode, as I was under the impression Python's bytecode format was supposed to be cross-platform. See e.g.: http://mail.python.org/pipermail/python-list/2004-March/213039.html

2 3

Re: [Python-Dev] Adding a conditional expression in Py3.0
by Edward C. Jones 29 Sep '05

29 Sep '05

Guido van Rossum wrote: file = os.path.abspath(file) if file else '?' ... These are all unreadable. In C "a ? b : c" is not used very often. A quick check of the Python source found 476 occurences. -1 to conditional expressions.

1 0