Mailman 3 February 2009 - Python-Dev

Financial aid for PyCon 2009 is now available
by Ted Pollari Feb. 2, 2009

Feb. 2, 2009

I'm happy to announce that the Python Software Foundation has allocated funds to help people attend PyCon 2009! If you would like to come to PyCon but can't afford it, the PSF may be able to help you pay for registration, lodging/hotel costs and transportation (flight etc.). Please see http://us.pycon.org/2009/registration/financial-aid/ for full details, or email pycon-aid(a)python.org with questions.

1 0

pprint(iterator)
by Raymond Hettinger Feb. 2, 2009

Feb. 2, 2009

It is becoming the norm in 3.x for functions to return iterators, generators, or views whereever possible. I had a thought that pprint() ought to be taught to print iterators: pprint(enumerate(seq)) pprint(map(somefunc, somedata)) pprint(permutations(elements)) pprint(mydict.items()) Currently, all four of those will print something like: >>> pprint(d.items()) <dict_items object at 0x00FA4470> >>> pprint(enumerate(d)) <enumerate object at 0x00FC2878> If pprint() is to give a more useful result, the question is how best to represent the iterators. In the examples for itertools, I adopted the convention of displaying results like a collection with no commas or enclosing delimiters: # chain('ABC', 'DEF') --> A B C D E F The equivalent for pprint would be the same for items, using space for items on one row or using linefeeds for output too long for one row. Another idea is to make-up an angle-bracket style to provide a visual cue for iterator output: <'A' 'B' 'C' 'D' 'E' 'F'> Perhaps with commas: <'A', 'B', 'C', 'D', 'E', 'F'> None of those ideas can be run through eval, nor do they identify the type of iterator. Perhaps these would be better: <enumerate object: 'A', 'B', 'C', 'D', 'E', 'F'> or iter(['A', 'B', 'C', 'D', 'E', 'F']) Do you guys have any thoughts on the subject? Raymond

17 35

Strange locale problem with Python 3
by Reto Schüttel Feb. 2, 2009

Feb. 2, 2009

Hi While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled over a strange locale-related problem on OS X. PyEphem is a library which can do astronomical computations like tracking the position of stars, planets and earth satellites relative to the earth's position. When testing out the Python 3 release of PyEphem I noticed that on my OS X laptop a lot of calculations were wrong (not completely wrong, but clearly not accurate) compared to Python 2.5. We (well mostly Brandon) were able to track down the problem to the TLE parser (TLE are data file containing the orbital elements of an object) which appears to read most values wrong with python 3. In fact it cut of the decimal parts of all floats (1.123232 got 1, etc). Manually setting LANG and LC_ALL to C solved the problem. It turns out that some parts of Python 3 got more locale dependent on some platforms. The only platform I am aware of is OS X, on Linux Python 3 appears to behave like Python 2.x did. In case of PyEphem the problem was in the C extension which got more locale dependent, for example atof() or scanf() with Python 3 now expected the german decimal-delimiter ',' instead of the '.' in floats (3.14 vs. 3,14). On the other hand the constructor of float still expects '.' all the time. But the built-in function strptime() honors locales with Python 3 and expects german week day. I've written a simple script and a simple C extension which illustrates the problem. Both the extension and the script run python 2.x and python 3, so you can easily compare the result while executing the script in different environments. I was only able to reproduce the problem on OS X (10.5) and using a german locale like "de_CH.UTF-8". When manually setting LC_ALL=C, the differences disappears. I can't imagine that his behavior was really intended, and I hope the test case helps you guys to identify/fix this problem. Download the test case from: http://github.com/retoo/py3k-locale-problem/tarball/master or get it using git: git://github.com/retoo/py3k-locale-problem.git You can use the following steps to build it: $ python2.5 setup.py build $ python3.0 setup.py build To run the tests with python 2.5, enter: $ (cd build/lib*-2.5; python2.5 py3k_locale_problem.py) ... for 3.0 ... $ (cd build/lib*-3.0; python3.0 py3k_locale_problem.py) In the file 'results.txt' you can see the output from my OS X system. Cheers, Reto Schüttel [1] http://rhodesmill.org/pyephem/

4 3

mail libraries streamlined support for ssl and starttls
by Lorenzo M. Catucci Feb. 2, 2009

Feb. 2, 2009

Sorry for being a pest here... still, I'd be grateful if someone could please try and take look at the patches I've posted on bugs.python.org for smtplib, imaplib and poplib, since I think they could be useful for a future 2.x release of the standard library, and I've verified they port almost as they are to python3. They are almost stupid, I know; still, smtp over ssl in the standard library is not working, and the starttls method is declared as being the preferred one since RFC 2595 time... """7. imaps and pop3s ports Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands. [...] """ Thank you all very much... Yours, lorenzo +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci(a)ccd.uniroma2.it | Università degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+

1 1

Fwd: Partial function application 'from the right'
by Ludvig Ericson Feb. 2, 2009

Feb. 2, 2009

Begin forwarded message: > From: Ludvig Ericson <ludvig(a)lericson.se> > Date: January 31, 2009 16:43:50 GMT+01:00 > To: Alexander Belopolsky <alexander.belopolsky(a)gmail.com> > Subject: Re: [Python-Dev] Partial function application 'from the > right' > > On Jan 31, 2009, at 04:02, Alexander Belopolsky wrote: > >> On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou >> <solipsis(a)pitrou.net> wrote: >> .. >>> If one writes X = partial.skip, it looks quite nice: >>> >>> split_one = partial(str.split, X, 1) >> >> Or even >> >> _ = partial.skip >> split_one = partial(str.split, _, 1) > > Or even > > … = partial.skip > split_one = partial(str.split, …, 1)

3 3

Should execv() call _run_exitfuncs()? If not, should _run_exitfuncs() be private?
by Rocky Bernstein Feb. 1, 2009

Feb. 1, 2009

As a hobby I've been writing a debugger. One of the commands,"restart", works by calling an execv(). You may need to do this when the program you are debugging is threaded or when one needs to ensure that all program state is reinitialized. Recently, I added remote debugging via TCP sockets and noticed that execv() in Python doesn't arrange exit hooks to get called. Should it? One can run _run_exitfuncs() from the atexit module, but the leading underscore of the function call suggests it is private. Should it be? Thanks

4 3