python-dev Summary for 2005-07-16 through 2005-07-31

Tony Meyer t-meyer at
Sat Aug 20 09:22:35 CEST 2005

[The HTML version of this Summary is available at]


PyPy Sprint in Heidelberg 22nd - 29th August 2005

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.

.. _PyPy:
.. _Heidelberg sprint:

Contributing thread:

- `Next PyPy sprint: Heidelberg (Germany), 22nd-29th of August

zlib 1.2.3 in Python 2.4 and 2.5

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.

Contributing thread:

- `zlib 1.2.3 is just out


Moving Python CVS to Subversion

Martin v. Löwis submitted `PEP 347`_, which outlines moving from CVS to SVN
for source code revision control of the Python repository, and moving from
SourceForge to for repository hosting.

Moving to SVN from CVS met with general favour, although most were undecided
about moving from to  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.

.. _PEP 347:

Contributing thread:

- `PEP: Migrating the Python CVS to Subversion

Exception Hierarchy in Python 3.0

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.

.. _Python 3.0:
.. _PEP 348:

Contributing thread:

- `Pre-PEP: Exception Reorganization for Python 3.0

Docstrings and the Official Documentation

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

.. _bug report:

Contributing thread:

- `should doc string content == documentation content?

Syntax suggestion: "while:"

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?"

Contributing thread:

- `while:

Sets in Python 2.5

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.

Contributing thread:

- `C api for built-in type set?

Skipped Threads

- `Some RFE for review
- `python/dist/src/Doc/lib emailutil.tex,1.11,1.12
- `read only files
- `builtin filter function
- `Weekly Python Patch/Bug Summary
- `Information request; Keywords: compiler compiler, EBNF, python, ISO 14977
- `installation of python on a Zaurus
- `python-dev summary for 2005-07-01 to 2005-07-15 [draft]
- `math.fabs redundant?

Skipped Threads (covered in the previous summary)

- `'With' context documentation draft (was Re: Terminology for PEP 343
- `Adding the 'path' module (was Re: Some RFE for review)
- `[C++-sig] GCC version compatibility


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

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:

- Steve Bethard (steven.bethard at
- Tim Lesher (tlesher at
- Tony Meyer (tony.meyer at

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 .  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 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 and should be used when looking up any
documentation for new code; otherwise use the current documentation as found
at .  PEPs (Python Enhancement Proposals) are
located at . To view files in the Python CVS
online, go to .
Reported bugs and suggested patches can be found at the SourceForge_ project

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`_.

.. _python-dev:
.. _SourceForge:
.. _python-dev mailing list:
.. _comp.lang.python:
.. _PEP Markup:

.. _Docutils:
.. _reST:
.. _reStructuredText:
.. _PSF:
.. _Python Software Foundation:

.. _last summary:
.. _original text file:
.. _archive:
.. _RSS feed:

More information about the Python-announce-list mailing list