Email Us
webmaster@python.org
 
 
© 2005
Python Software Foundation
  

python-dev Summary for 2005-06-01 through 2005-06-15

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-06-01_2005-06-15.html]

Summary Announcements

Bug Day: Saturday, June 25th 2005

AMK organized another Python Bug Day on Saturday, June 25th. Hope you got a chance to help out!

Contributing Threads:

[SJB]

FishEye for Python CVS

Peter Moore has kindly set up Fish Eye for the Python CVS repository. FishEye is a repository browsing, searching, analysis and monitoring tool, with great features like RSS feeds, Synthetic changesets, Pretty ediffs and SQL like searches. Check it out!

Contributing Threads:

[SJB]

PyPy Sprint: July 1st - 7th 2005

The next PyPy sprint is scheduled right after EuroPython 2005 in Gothenborg, Sweden. It will focus mainly on translating PyPy to lower level backends, so as to move away from running PyPy on top of the CPython interpreter. There will be newcomer-friendly introductions, and other topics are possible, so if you have any interest in PyPy, now is the time to help out!

Contributing Threads:

[SJB]

Reminder: Google's Summer of Code

Just a reminder that the friendly folks at Python have set up a wiki and a mailing list for questions about Google's Summer of Code. For specific details on particular projects (e.g. what needs done to complete Python SSL support) participants may also ask questions to the Python-Dev list.

[SJB]

hashlib Review Request

Gregory P. Smith noted that he has finished up the hashlib work he started on a few months ago for patches 935454 and 1121611 (where the final patch is). He feels that the patch is ready, and would like anyone interested to review it; the patch incorporates both OpenSSL hash support and SHA256+SHA512 support in a single module. The documentation can be accessed separately, for convenience.

Contributing Threads:

[TAM]

Summaries

PEP 343 Progress

The PEP 343 discussions were mostly concluded. Guido posted the newest version of the PEP to both Python-Dev and Python-List and the discussions that followed were brief and mostly in agreement with the proposal.

The PEP 343 syntax was modified slightly to require parentheses if VAR is a comma-separated list of variables. This made the proposal forward-compatible to extending the with-block for multiple resources. In the favored extension, the with-block would take multiple expressions in a manner analogous to import statements:

with EXPR1 [as VAR1], EXPR2 [as VAR2], ...:
    BLOCK

However, if this extension becomes part of Python, it will likely enter some time after Python 2.5, once users have a better idea of what with-block use-cases look like.

There were also some brief discussions about how with-blocks should behave in the presence of async exceptions like the KeyboardInterrupt generated from a ^C. While it seemed like it would be a nice property for with-blocks to guarantee that the __exit__ methods would still be called in the presence of async exceptions, making such a guarantee proved to be too complicated. Thus the final conclusion, as summarized by Nick Coghlan, was that "with statements won't make any more guarantees about this than try/finally statements do".

Contributing Threads:

[SJB]

Do-While Loops

Raymond Hettinger asked for a "dowhile" loop of the form:

dowhile <cond>:
    <body>

which would run <body> once before testing the <cond>, and then proceed as a normal while-loop. He was subsequently referred to PEP 315, which proposes a slightly different syntax for a similar purpose.

The discussion expanded to not only do-while loops, but also loops with break conditions at locations other than the beginning and the end of a loop. A variety of syntax proposals were suggested, but none seemed compellingly better than the current syntax:

while True:
    ...
    if <cond>:
        break
    ...

which supports putting the condition(s) at any location in the loop.

Contributing Threads:

[SJB]

Reference Counting in Module Globals

Both Michael Hudson and Skip Montanaro noticed that Py_INCREFs appeared to be unnecessary when adding an object to a module's globals. Armin Rigo explained that after a module is initialized, the import mechanism makes a "hidden" copy of the module's dict so that the module can be reloaded. This means that objects added as module globals will always have an extra reference count in this hidden dict.

However, Armin Rigo agreed with Michael Hudson that this explanation was no longer applicable after an interpreter shutdown. The best conclusion he could draw in this a situation: "it's all quite obscure".

Contributing Threads:

[SJB]

Reorganising the standard library (again)

The ever-popular topic of reorganising the standard library came up again this fortnight, courtesy of Reinhold Birkenfeld. The questions posed included hierarchy (flat/nested), third party modules, size (batteries included or not), and the standard GUI toolkit.

As usual, there was a great deal of discussion, but not a great deal of consensus about any of these (other than that including ElementTree in the standard library would be good), and given the amount of breakage this would involve (and that Guido didn't weigh in at all), it seems unlikely that much will change before Python 3000; although Josiah Carlson indicated that he had a patch that would avoid a lot of breakage.

Contributing Threads:

[TAM]

First Mac-tel, now Py-tel?

Guido mentioned that Intel has a free (as in beer) C compiler for Linux, and that a friend of his (who is involved in its production and marketing) would like to see how it performs with Python. The compiler wasn't news to some of the -dev crowd, though, with Martin v. Löwis pointing out a bug report on the compiler, as well as a patch, and a message indicating that some people had problems with the resulting interpreter.

Martin pointed out that there were some old (2002 and 2004) results indicating that the Intel compiler was slightly faster, but couldn't find any results for the latest version. Michael Hoffman gave summaries of more testing, which gave a 16% speed increase. He felt that, while this was significant, he wasted a lot of time dealing with resulting problems with extension modules, and so it doesn't use as much any more.

Contributing Threads:

[TAM]

sys.path Behaviour

Reinhold Birkenfeld noticed that sys.path's first element is '' in interactive sessions, but the directory containing the script otherwise, and wondered if this was intentional. Guido clarified that he's always liked it this way, so that if you use os.path.join to join it with a script name you don't get a spurious "." preprended.

The "absolutizing" of sys.path entries, however, is reasonably new; Bob Ippolito pointed out that is also problematic with regards to path hooks. He has a patch to fix it, but hasn't had a chance to commit it; Phillip J. Eby noted that the patch doesn't fix completely fix it, however, and indicated that fixing site.py with respect to PEP 302 will be quite challenging.

Contributing Threads:

[TAM]

More on old bugs

The discussion about what to do with old bugs continued this fortnight. Against the concern about prematurely closing old bugs, there was the suggestion that given that there are such a huge number of open bug reports, and since closed bugs can be reopened, this wasn't such a problem. It was suggested that the act of closing a bug might trigger activity to get it fixed, if necessary. The thread died off before a consensus was reached, unfortunately.

Contributing Threads:

[TAM]

Improved pseudo-switch statements

Skip Montanaro has been playing around with getting the Python compiler to recognize switch-like statements and generate O(1) code out of them. The rules are that the object being compared ('x') can be any expression, but must be precisely the same in each elif clause, the comparison operator must be "==", and the right-hand-side of the test must evaluate to a simple hashable constant. However, if evaluating 'x' has side-effects, then this would break code.

Various people felt that it was unwise to allow 'x' to be any expression; Anthony Baxter suggested that one could allow any local object that didn't define a comparison operator.

Contributing Threads:

[TAM]

Epilogue

Introduction

This is a summary of traffic on the python-dev mailing list from June 01, 2005 through June 15, 2005.

It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive of previous summaries is available online.

An RSS feed of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org).

This is the fifth summary written by the python-dev summary cabal of Steve Bethard, Tim Lesher, and Tony Meyer.

To contact us, please send email:

  • Steve Bethard (steven.bethard at gmail.com)
  • Tim Lesher (tlesher at gmail.com)
  • Tony Meyer (tony.meyer at gmail.com)

Do not post to comp.lang.python if you wish to reach us.

The Python Software Foundation is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps.

Commenting on Topics

To comment on anything mentioned here, just post to comp.lang.python (or email python-list at python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev!

How to Read the Summaries

The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge project page.

Please note that this summary is written using reStructuredText. Any unfamiliar punctuation is probably markup for reST (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. I do suggest learning reST, though; it's simple and is accepted for PEP markup and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow me to guarantee you will be able to run the text version of this summary through Docutils as-is unless it is from the original text file.