[Python-Dev] python-dev Summary for 2005-07-16 through 2005-07-31 [draft]

Tony Meyer t-meyer at ihug.co.nz
Mon Aug 15 05:46:19 CEST 2005

Here's July Part Two.  As usual, if anyone can spare the time to proofread
this (it's fairly short this fortnight!), that would be great!  Please send
any corrections or suggestions to Tim (tlesher at gmail.com), Steve
(steven.bethard at gmail.com) and/or me, rather than cluttering the list.


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: http://codespeak.net/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`_, covering changing from CVS to SVN for
source code revision  control of the Python repository, and moving from
hosting the repository on sourceforge.net to  python.org.

Moving to SVN from CVS met with general favour from most people, 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.

.. _PEP 347: http://www.python.org/peps/pep-0347.html

Contributing thread:

- `PEP: Migrating the Python CVS to Subversion
<http://mail.python.org/pipermail/python-dev/2005- July/054950.html>`__

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: http://www.python.org/peps/pep-3000.html
.. _PEP 348: http://www.python.org/peps/pep-0348.html

Contributing thread:

- `Pre-PEP: Exception Reorganization for Python 3.0
<http://mail.python.org/pipermail/python-dev/2005 -July/055018.html>`__

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: http://python.org/sf/1243553

Contributing thread:

- `should doc string content == documentation content?
<http://mail.python.org/pipermail/python- dev/2005-July/054928.html>`__

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
<http://mail.python.org/pipermail/python-dev/2005- July/054902.html>`__
- `read only files
- `builtin filter function
- `Weekly Python Patch/Bug Summary
<http://mail.python.org/pipermail/python-dev/2005- July/054921.html>`__
- `Information request; Keywords: compiler compiler, EBNF, python, ISO 14977
- `installation of python on a Zaurus
<http://mail.python.org/pipermail/python-dev/2005- July/054937.html>`__
- `python-dev summary for 2005-07-01 to 2005-07-15 [draft]
<http://mail.python.org/pipermail/python- dev/2005-July/054948.html>`__
- `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)
<http://mail.python.org/pipermail/python- dev/2005-July/054894.html>`__
- `[C++-sig] GCC version compatibility
<http://mail.python.org/pipermail/python-dev/2005- July/054895.html>`__

More information about the Python-Dev mailing list