[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-07-16_2005-07-31.html]
Heidelberg University in Germany will host a PyPy sprint from 22nd August to 29th August. The sprint will push towards the 0.7 release of PyPy which hopes to reach Python 2.4.1 compliancy and to have full, direct, translation into a low level language instead of reinterpretation through CPython. If you'd like to help out, this is a great place to start!
For more information, see PyPy's Heidelberg sprint page.
Trent Mick supplied a patch for updating Python from zlib 1.2.1 to zlib 1.2.3, which eliminates some potential security vulnerabilities. Python will move to this new version of zlib in both the maintenance 2.4 branch and the main (2.5) branch.
Martin v. Lowis submitted PEP 347, which outlines moving from CVS to SVN for source code revision control of the Python repository, and moving from SourceForge to python.org for repository hosting.
Moving to SVN from CVS met with general favour, although most were undecided about moving from sourceforge.net to python.org. The additional administration requirements of the move were the primary concern, and moving to an alternative host was suggested. Martin is open to including suggestions for alternative hosts in the PEP, but is not interested in carrying out such research himself; as such, if alternative hosts are to be included, someone needs to volunteer to collect all the required information and submit it to Martin.
Discussion about the conversion and the move is continuing in August.
Brett Cannon posted the first draft of PEP 348, covering reorganisation of exceptions in Python 3.0. The initial draft included major changes to the hierarchy, requiring any object raised to inherit from a certain superclass, and changing bare 'except' clauses to catch a specific superclass. The latter two proposals didn't generate much comment (although Guido vacillated between removing bare 'except' clauses and not), but the proposed hierarchy organisation and renaming was hotly discussed.
Nick Coghlan countered each revision of Brett's maximum-changes PEP with a minimum-changes PEP, each evolving through python-dev discussion, and gradually moving to an acceptable middle ground. At present, it seems that the changes will be much more minor than the original proposal.
The thread branched off into comments about Python 3.0 changes in general. The consensus was generally that although backwards compatibility isn't required in Python 3.0, it should only be broken when there is a clear reason for it, and that, as much as possible, Python 3.0 should be Python 2.9 without a lot of backwards compatibility code. A number of people indicated that they were reasonably content with the existing exception hierarchy, and didn't feel that major changes were required.
Guido suggested that a good principle for determining the ideal exception hierarchy is whether there's a use case for catching the common base class. Marc-Andre Lemburg pointed out that when migrating code changes in Exception names are reasonably easy to automate, but changes in the inheritance tree are much more difficult.
Many exceptions were discussed at length (e.g. WindowsError, RuntimeError), with debate about whether they should continue to exist in Python 3.0, be renamed, or be removed. The PEP contains the current status for each of these exceptions.
The PEP evolution and discussion are still continuing in August, and since this is for Python 3.0, are likely to be considered open for some time yet.
A new bug report pointed out that the docstring help for cgi.escape was not as detailed as that in the full documentation, prompting Skip Montanaro to ask whether this should be the case or not. Several reasons were outlined why docstrings should be more of a "quick reference card" than a "textbook" (i.e. maintain the status quo). Tim Peters suggested that tools to extract text from the full documentation would be a more sensible method of making the "textbook" available from help()/pydoc; if anyone is interested, then this would probably be the best way to start implementing this.
Martin Blais suggested "while:" as a syntactic shortcut for "while True:". The suggestion was shot down pretty quickly; not only is "while:" less explicit than "while True:", but it introduces readability problems for the apparently large number of people who, when reading "while:", immediately think "while what?"
In Python 2.4, there is no C API for the built-in set type; you must use PyObject_Call(), etc. as you would in accessing other Python objects. However, in Python 2.5, Raymond Hettinger plans to introduce a C API along with a new implementation of the set type that uses its own data structure instead of forwarding everything to dicts.
This is a summary of traffic on the python-dev mailing list from July 16, 2005 through July 31, 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 8th summary written by the python-dev summary cabal of Steve Bethard, Tim Lesher, and Tony Meyer.
To contact us, please send email:
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.
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. We 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 us 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.