Mailman 3 October 2001 - Python-Dev

slicing of structseq objects fails
by Jack Jansen Oct. 31, 2001

Oct. 31, 2001

Python-devvers, Russel Owen reported the following bug, and it turns out to be a general bug, not a MacPython one: slicing the structseq-style tuples returned by time.gmtime() returns a sequence with NULLs in it. Shortly afterwards Python crashes on my SGI. Any takers? Recently, Russell E Owen <owen(a)astro.washington.edu> said: > The following code fails (G4, MacOS 9.2.1) in Classic MacPython 2.2b1: > > import time > > currUTCTuple= time.gmtime(time.time()) > print "currUTCTuple=%r" % (currUTCTuple,) > print "currUTCTuple[3:6]=%r" % (currUTCTuple[3:6],) > fmtTime = "%s:%02i:%02i" % currUTCTuple[3:6] > print "formatted time = ", fmtTime > > It displays (<NULL>, <NULL>, <NULL>) for currUTCTuple[3:6], > ... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 4

Misleading error message when multiple arguments for write()
by Hamish Lawson Oct. 30, 2001

Oct. 30, 2001

The reference to 'tuple' in the error message below seems misleading. Too many arguments have been passed rather than a tuple. Traceback (most recent call last): File "C:\Temp\demo.py", line 3, in ? sys.stdout.write("a", "b") TypeError: argument must be string or read-only character buffer, not tuple Hamish Lawson ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

2 1

Slices and "==" optimization
by M.-A. Lemburg Oct. 30, 2001

Oct. 30, 2001

While writing yet another XML parser I have come across two things which would seem nice to have: 1. Even though you can construct slice objects in Python using slice(left,right), you can't really do anything with them; at least not on the standard types (Numeric's arrays work with them just fine). Couldn't we add some functionality which makes them compatible to lists and tuples (and perhaps even in a generic way for other sequences using PySequence_GetItem()) too ? I thinking of extending the __getitem__ hook to accept slice objects. You could then maintain slices to an object in say a list and apply them to the underlying text as needed, e.g. s = slice(1,4) l = range(10) l[s] == [1, 2, 3] 2. Looking through the code for '==' the optimization for 'a == a' seems too far down the call stack. Since interning strings makes this case rather common, I'd suggest to lift the optimization into the ceval loop (right along side with the INT op INT optimization). Thoughts ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

3 2

Re: OS/2 VAC++ patches
by Michael Muller Oct. 30, 2001

Oct. 30, 2001

Andrew, Thanks for reviewing my patches. I am posting a new patch in response to your comments on *749. Andrew MacIntyre wrote: > I have looked at Michael Muller's VAC++ patches, and added comments as > followups. > > In summary: > 473749 - has several (minor IMO) stylistic issues (addition of OS/2 > #ifdefs). The intent of the changes looks OK, as do most of > the actual changes (those in OS/2 VAC specific files or > existing OS/2 #ifdefs). > 474169 - looks good to go (changes inside existing OS/2 #ifdef) > 474500 - looks good to go (isolated to OS/2 specific file) > > Comments on the stylistic issues? > > -- > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370 > andymac(a)pcug.org.au | Belconnen ACT 2616 > Web: http://www.andymac.org/ | Australia ============================================================================= michaelMuller = mmuller(a)enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- There is no concept that is more demeaning to the human spirit than the notion that our freedom must be limited in the interests of our own protection. =============================================================================

1 0

2.2 article updated
by Martin v. Loewis Oct. 30, 2001

Oct. 30, 2001

> BTW, I call PEP 261, "Support for "wide" Unicode characters", not > finally accepted and not implemented. Is that correct? Is it going > to be finished before 2.2final, or should I simply describe it as > partially implemented in the final version of the text? To my knowledge, it is completely implemented. You may mention that --disable-unicode is now also supported. There is atleast one error in the PEP, namely that the define for wide Unicode Py_UNICODE_WIDE (Py_UNICODE_SIZE also exists, but isn't used except to define Py_UNICODE_WIDE). I'm also not sure certain the all codecs handle all surrogate cases correctly in all circumstances, but that is in the realm of bug reports. One further Unicode change: The bullet item "When presented with a Unicode filename on Windows ..." should be extended with "On Unix, the locale's character set is used if nl_langinfo(CODESET) is available." Two new builtins are missing in your text, OverflowWarning and super. HTH, Martin

1 0

2.2 article updated
by Andrew Kuchling Oct. 30, 2001

Oct. 30, 2001

I've updated the 2.2 article with a section that gives an overview of the type/class changes. At this point the text should be essentially done, except for whatever small changes get into CVS between now and 2.2final. Please take a look and send me any comments: http://www.amk.ca/python/2.2/ (Oops! Michael McLay just sent me a note pointing out that I refer to .__get__() as .get() in a few places. So don't bother reporting that.) If your favorite patch or improvement isn't mentioned, please let me know. Also inform me if you aren't mentioned as a contributor to a patch. BTW, I call PEP 261, "Support for "wide" Unicode characters", not finally accepted and not implemented. Is that correct? Is it going to be finished before 2.2final, or should I simply describe it as partially implemented in the final version of the text? --amk

1 0

Slices and "==" optimization
by Martin v. Loewis Oct. 30, 2001

Oct. 30, 2001

> I thinking of extending the __getitem__ hook to accept slice objects Please have a look at http://sourceforge.net/tracker/?func=detail&aid=459235&group_id=5470&atid=1… It's a known problem, but Guido won't fix it anytime soon. So I guess contributions are welcome. > Looking through the code for '==' the optimization for 'a == a' > seems too far down the call stack. Since interning strings makes > this case rather common, I'd suggest to lift the optimization into > the ceval loop As with all optimizations: Patches to just improve the performance are unacceptable unless accompanied by some hard numbers to show that they really do have the desired effect. History shows that patches to just improve the performance may be unacceptable even if accompanied by such numbers. Normally, Tim will construct a scenario where the patch causes a slow-down, and argue that this is a common scenario :-) Regards, Martin

3 2

Re: test_asynchat.py broken on Windows
by Jeremy Hylton Oct. 30, 2001

Oct. 30, 2001

I think there are at least three things wrong, depending on what you count as wrong. The test is hanging because it spawns a thread, which Python will prevent Python from exiting until the thread exits. The thread doesn't exit because it's waiting for input from the client. The client doesn't send it any input because of the exception. thing wrong #1: It would probably make sense to change test_asynchat.py to use a daemon thread so that it can't prevent the test suite from exiting. thing wrong #2: I don't think the ENONET being returned by connect_ex() makes any sense. My guess is that connect_ex() is (and always has been) broken on Windows. Could you apply this patch and see what happens: Index: socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.190 diff -c -c -r1.190 socketmodule.c *** socketmodule.c 2001/10/28 12:31:33 1.190 --- socketmodule.c 2001/10/29 23:14:18 *************** *** 1268,1274 **** --- 1268,1278 ---- res = connect(s->sock_fd, addr, addrlen); Py_END_ALLOW_THREADS if (res != 0) + #ifdef MS_WINDOWS + res = WSAGetLastError(); + #else res = errno; + #endif return PyInt_FromLong((long) res); } thing wrong #3: From the winsock documentation for connect(), it looks like there are more errors we should be catching in the test that includes EWOULDBLOCK and EALREADY. I don't think this would affect your test, though. thing wrong #4: It doesn't look to me like the connect() call in test_asynchat.py is guaranteed to succeed. It should succeed almost every time, but there's some small chance it will fail. Perhaps the test should be more robust about that. That's four things, but I don't think the last thing is all that wrong. Jeremy

3 2

[development doc updates]
by Fred L. Drake Oct. 30, 2001

Oct. 30, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Re-arranged the material in Chapter 2 (built-in things) to make it easier to start off with. Functions come before Types and Exceptions, and file objects are promoted one level in the outline, making them easier to find (they now appear in the table of contents instead of being hidden in the "Other Objects" category).

1 0

[UPDATE] PEP 274, Dict Comprehensions
by barry＠zope.com Oct. 29, 2001

Oct. 29, 2001

Attached is the latest version of PEP 274 for dictionary comprehensions, similar to list comprehensions. The first version of this PEP wasn't posted here, but several people saw the cvs checkin and sent in comments, which have now been incorporated. Enjoy, -Barry -------------------- snip snip -------------------- PEP: 274 Title: Dict Comprehensions Version: $Revision: 1.2 $ Last-Modified: $Date: 2001/10/29 18:46:59 $ Author: barry(a)zope.com (Barry A. Warsaw) Status: Draft Type: Standards Track Created: 25-Oct-2001 Python-Version: 2.3 Post-History: 29-Oct-2001 Abstract PEP 202 introduces a syntactical extension to Python called the "list comprehension"[1]. This PEP proposes a similar syntactical extension called the "dictionary comprehension" or "dict comprehension" for short. You can use dict comprehensions in ways very similar to list comprehensions, except that they produce Python dictionary objects instead of list objects. Proposed Solution Dict comprehensions are just like list comprehensions, except that you group the expression using curly braces instead of square braces. Also, the left part before the `for' keyword expresses both a key and a value, separated by a colon. (There is an optional part of this PEP that allows you to use a shortcut to express just the value.) The notation is specifically designed to remind you of list comprehensions as applied to dictionaries. Rationale There are times when you have some data arranged as a sequences of length-2 sequences, and you want to turn that into a dictionary. In Python 2.2, the dictionary() constructor will take an optional keyword argument that indicates specifically to interpret a sequences of length-2 sequences as key/value pairs, and turn them into a dictionary. However, the act of turning some data into a sequence of length-2 sequences can be inconvenient or inefficient from a memory or performance standpoint. Also, for some common operations, such as turning a list of things into a set of things for quick duplicate removal or set inclusion tests, a better syntax can help code clarity. As with list comprehensions, an explicit for loop can always be used (and in fact was the only way to do it in earlier versions of Python). But as with list comprehensions, dict comprehensions can provide a more syntactically succinct idiom that the traditional for loop. Examples >>> print {i : chr(65+i) for i in range(4)} {0 : 'A', 1 : 'B', 2 : 'C', 3 : 'D'} >>> print {k : v for k, v in someDict.iteritems()} == someDict.copy() 1 >>> print {x.lower() : 1 for x in list_of_email_addrs} {'barry(a)zope.com' : 1, 'barry(a)python.org' : 1, 'guido(a)python.org' : 1} >>> def invert(d): ... return {v : k for k, v in d.iteritems()} ... >>> d = {0 : 'A', 1 : 'B', 2 : 'C', 3 : 'D'} >>> print invert(d) {'A' : 0, 'B' : 1, 'C' : 2, 'D' : 3} Open Issues - There is one further shortcut we could adopt. Suppose we wanted to create a set of items, such as in the "list_of_email_addrs" example above. Here, we're simply taking the target of the for loop and turning that into the key for the dict comprehension. The assertion is that this would be a common idiom, so the shortcut below allows for an easy spelling of it, by allow us to omit the "key :" part of the left hand clause: >>> print {1 for x in list_of_email_addrs} {'barry(a)zope.com' : 1, 'barry(a)python.org' : 1, 'guido(a)python.org' : 1} Or say we wanted to map email addresses to the MX record handling their mail: >>> print {mx_for_addr(x) for x in list_of_email_addrs} {'barry(a)zope.com' : 'mail.zope.com', 'barry(a)python.org' : 'mail.python.org, 'guido(a)python.org' : 'mail.python.org, } Questions: what about nested loops? Where does the key come from? The shortcut probably doesn't save much typing, and comes at the expense of legibility, so it's of dubious value. - Should nested for loops be allowed? The following example, taken from an earlier revision of this PEP illustrates the problem: >>> print {k, v for k in range(4) for v in range(-4, 0, 1)} The intent of this example was to produce a mapping from a number to its negative, but this code doesn't work because -- as in list comprehensions -- the for loops are nested, not in parallel! So the value of this expression is actually {0: -1, 1: -1, 2: -1, 3: -1} which seems of dubious value. For symmetry with list comprehensions, perhaps this should be allowed, but it might be better to disallow this syntax. Implementation The semantics of dictionary comprehensions can actually be modeled in stock Python 2.2, by passing a list comprehension to the builtin dictionary constructor: >>> dictionary([(i, chr(65+i)) for i in range(4)]) This has two dictinct disadvantages from the proposed syntax though. First, it's isn't as legible as a dict comprehension. Second, it forces the programmer to create an in-core list object first, which could be expensive. References [1] PEP 202, List Comprehensions http://www.python.org/peps/pep-0202.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil fill-column: 70 End:

5 10