[The HTML version of this Summary is available at
QOTF: Quote of the Fortnight
Some wise words from Donovan Baarda in the PEP 347 discussions:
It is true that some well designed/developed software becomes =
very quickly. However, it still takes heavy use over time to prove that.
- `PEP: Migrating the Python CVS to Subversion
The PEP editors have introduced a new PEP category: "Process", for PEPs =
don't fit into the "Standards Track" and "Informational" categories. =
detail can be found in `PEP 1`_, which is itself a Process PEP.
... _PEP 1: http://www.python.org/peps/pep-0001.html
- `new PEP type: Process
Tentative Schedule for 2.4.2 and 2.5a1 Releases
Python 2.4.2 is tentatively scheduled for a mid-to-late September =
and a first alpha of Python 2.5 for March 2006 (with a final release =
May/June). This means that a PEP for the 2.5 release, detailing what =
be included, will likely be created soon; at present there are various
accepted PEPs that have not yet been implemented.
- `plans for 2.4.2 and 2.5a1
Moving Python CVS to Subversion
The `PEP 347`_ discussion from last fortnight continued this week, with =
revision of the PEP, and a lot more discussion about possible version
control software (RCS) for the Python repository, and where the =
should be hosted. Note that this is not a discussion about bug =
which will remain with Sourceforge (unless a separate PEP is developed =
Many revision control systems were extensively discussed, including
`Subversion`_ (SVN), `Perforce`_, `Mercurial`_, and `Monotone`_. =
system is moved to, it should be able to be hosted somewhere (if
*.python.org, then it needs to be easily installable), needs to have
software available to convert a repository from CVS, and ideally would =
open-source; similarity to CVS is also an advantage in that it requires =
smaller learning curve for existing developers. While Martin isn't =
to discuss every system there is, he will investigate those that make =
curious, and will add other people's submissions to the PEP, where
The thread included a short discussion about the authentication =
that svn.python.org will use; svn+ssh seems to be a clear winner, and a =
repository will be setup by Martin next fortnight.
The possibility of moving to a distributed revision control system
(particularly `Bazaar-NG`_) was also brought up. Many people liked the =
of using a distributed revision control system, but it seems unlikely =
Bazaar-NG is mature enough to be used for the main Python repository at =
current time (a move to it at a later time is possible, but outside the
scope of the PEP). Distributed RCS are meant to reduce the barrier to
participation (anyone can create their own branches, for example); =
is also implemented in Python, which is of some benefit. James Y Knight
pointed out `svk`_, which lets developers create their own branches =
In general, the python-dev crowd is in favour of moving to SVN. Initial
concern about the demands on the volunteer admins should the repository =
hosted at svn.python.org were addressed by Barry Warsaw, who believes =
the load will be easily managed with the existing volunteers. Various
alternative hosts were discussed, and if detailed reports about any of =
are created, these can be added to the PEP.
While the fate of all PEPS lie with the BDFL (Guido), it is likely that =
preferences of those that frequently check in changes, the pydotorg =
and the release managers (who have all given favourable reports so far),
will have a significant effect on the pronouncement of this PEP.
... _PEP 347: http://www.python.org/peps/pep-0347.html
... _svk: http://svk.elixus.org/
... _Perforce: http://www.perforce.com/
... _Subversion: http://subversion.tigris.org/
... _Monotone: http://venge.net/monotone/
... _Bazaar-NG: http://www.bazaar-ng.org/
... _Mercurial: http://www.selenic.com/mercurial/
- `PEP: Migrating the Python CVS to Subversion
- `PEP 347: Migration to Subversion
- `Hosting svn.python.org
- `Fwd: Distributed RCS
- `cvs to bzr?
- `Distributed RCS
- `Fwd: PEP: Migrating the Python CVS to Subversion
- `On distributed vs centralised SCM for Python
PEP 348: Exception Hierarchy in Python 3.0
This fortnight mostly concluded the previous discussion about `PEP =
which sets out a roadmap for changes to the exception hierarchy in =
3.0. The proposal was heavily scaled back to retain most of the current
exception hierarchy unchanged. A new exception, BaseException, will be
introduced above Exception in the current hierarchy, and =
and SystemExit will become siblings of Exception. The goal here is =
will now do the right thing for most cases, that is, it will catch all =
exceptions that you can generally recover from. The PEP would also move
NotImplementedError out from under RuntimeError, and alter the semantics =
the bare except so that::
is the equivalent of::
Only BaseException will appear in Python 2.5. The remaining =
will not occur until Python 3.0.
... _PEP 348: http://www.python.org/peps/pep-0348.html
- `Pre-PEP: Exception Reorganization for Python 3.0
- `PEP, take 2: Exception Reorganization for Python 3.0
- `Exception Reorg PEP checked in
- `PEP 348: Exception Reorganization for Python 3.0
- `Major revision of PEP 348 committed
- `Exception Reorg PEP revised yet again
- `PEP 348 and ControlFlow
- `PEP 348 (exception reorg) revised again
Moving towards Unicode
Neil Schemenauer presented `PEP 349`_, which tries to ease the =
Python 3.0, in which there will be a bytes() type for byte data and a =
type for text data. Currently to convert an object to text, you have =
* Call str(). This breaks with a UnicodeEncodeError if the object is of =
unicode (or a subtype) or can only represent itself in unicode and =
returns unicode from __str__.
* Call unicode(). This can break external code that is not yet =
and that passed a str object to your code but got a unicode object back.
* Use the "%s" format specifier. This breaks with a UnicodeEncodeError =
the object can only represent itself in unicode and therefore returns
unicode from __str__.
`PEP 349`_ attempts to address this problem by introducing a text() =
which returns str or unicode instances unmodified, and returns the =
calling __str__() on the object otherwise. Guido preferred to instead =
the restrictions on str() to allow it to return unicode objects. Neil
implemented such a patch, and found that it broke only two test cases. =
discussion stopped shortly after Neil's report however, so it was =
any permanent changes had been agreed upon.
Guido made a few other Python 3.0 suggestions in this thread:
* The bytes() type should be mutable with a corresponding frozenbytes()
* Opening a file in binary or text mode would cause it to return bytes() =
str() objects, respectively
* The file type should grow a getpos()/setpos() pair that are identical =
tell()/seek() when a file is open in binary mode, and which work like
tell()/seek() but on characters instead of bytes when a file is opened =
However, none of these seemed to be solid commitments.
... _PEP 349: http://www.python.org/peps/pep-0349.html
- `PEP: Generalised String Coercion
- `Generalised String Coercion
PEP 344 and reference cycles
Armin Rigo brought up an issue with `PEP 344`_ which proposes, among =
things, adding a __traceback__ attribute to exceptions to avoid the =
of extracting it from sys.exc_info(). Armin pointed out that if =
grow a __traceback__ attribute, every statement::
except Exception, e:
will create a cycle::
Despite the fact that Python has cyclic garbage collection, there are =
some situations where cycles like this can cause problems. Armin showed =
example of such a case::
except Exception, e:
e_type, e_value, e_tb =3D sys.exc_info()
Even in current Python, instances of the X class are uncollectible. When
garbage collection runs and tries to collect an X object, it calls the
__del__() method. This creates the cycle::
The X object itself is available through this cycle (in
``f_locals['self']``), so the X object's refcount does not drop to 0 =
__del__() returns, so it cannot be collected. The next time garbage
collection runs, it finds that the X object has not been collected, =
its __del__() method again and repeats the process.
Tim Peters suggested this problem could be solved by declaring that
__del__() methods are called exactly once. This allows the above X =
be collected because on the second run of the garbage collection, =
is not called again. Thus, the refcount of the X object is not =
and so it is collected by garbage collection. However, guaranteeing =
__del__() is called only once means keeping track somehow of which =
__del__() methods were called, which seemed somewhat unattractive.
There was also brief talk about removing __del__ in favor of weakrefs, =
those waters seemed about as murky as the garbage collection ones.
... _PEP 344: http://www.python.org/peps/pep-0344.html
- `__traceback__ and reference cycles
Style for raising exceptions
Guido explained that these days exceptions should always be raised as::
raise SomeException("some argument")
raise SomeException, "some argument"
The second will go away in Python 3.0, and is only present now for =
compatibility. (It was necessary when strings could be exceptions, in =
to pass both the exception "type" and message.) PEPs 8_ and 3000_ were
... _8: http://www.python.org/peps/pep-0008.html
... _3000: http://www.python.org/peps/pep-3000.html
- `PEP 8: exception style
- `FW: PEP 8: exception style
Skipping list comprehensions in pdb
When using pdb, the only way to skip to the end of a loop is to set a
breakpoint on the line after the loop. Ilya Sandler suggested adding an
optimal numeric argument to pdb's "next" comment to indicate how many =
of code should be skipped. Martin v. L=F6wis pointed out that this =
from gdb's "next <n>" command, which does "next" n times. Ilya =
implementing gdb's "until" command instead, which gained Martin's =
It was also pointed out that pdb is one of the less Pythonic modules,
particularly in terms of the ability to subclass/extend, and would be a =
candidate for rewriting, if anyone had the inclination and time.
- `pdb: should next command be extended?
- `an alternative suggestion, Re: pdb: should next command be extended?
Sets in Python 2.5
Raymond Hettinger has been checking-in the new implementation for sets =
Python 2.5. The implementation is based heavily on dictobject.c, the =
for Python dict() objects, and generally deviates only when there is an
obvious gain in doing so. Raymond posted a proposed C API sets; no =
were forthcoming and it was implemented for Py2.5 without changes.
- `[Python-checkins] python/dist/src/Objects setobject.c, 1.45, 1.46
- `Discussion draft: Proposed Py2.5 C API for set and frozenset objects
Deferred Threads (for next time)
- `SWIG and rlcompleter
- `Extension of struct to handle non byte aligned values?
- `Syscall Proxying in Python
- `__autoinit__ (Was: Proposal: reducing self.x=3Dx; self.y=3Dy; =
- `Weekly Python Patch/Bug Summary
- `PEP 342 Implementation
- `String exceptions in Python source
- `[ python-Patches-790710 ] breakpoint command lists in pdb
- `[C++-sig] GCC version compatibility
- `PyTuple_Pack added references undocumented
- `PEP-- Context Managment variant
- `Sourceforge CVS down?
- `PSF grant / contacts
- `Python + Ping
- `Terminology for PEP 343
- `dev listinfo page (was: Re: Python + Ping)
- `set.remove feature/bug
- `Extension to dl module to allow passing strings from native function
- `build problems on macosx (CVS HEAD)
- `request for code review - hashlib - patch #1121611
- `python-dev Summary for 2005-07-16 through 2005-07-31 [draft]
- `string_join overrides TypeError exception thrown in generator
- `implementation of copy standard lib
- `xml.parsers.expat no userdata in callback functions
This is a summary of traffic on the `python-dev mailing list`_ from
August 01, 2005 through August 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).
Tim Lesher has had to bow out from the summaries for now; many thanks
to him for the contributions he made over the last few months.
This is the 1st summary written by the python-dev summary confederacy of
Steve Bethard and Tony Meyer (Thanks Tim!).
To contact us, please send email:
- Steve Bethard (steven.bethard 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=20
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. =20
Commenting on Topics
To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email firstname.lastname@example.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
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 =3D); 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: http://www.python.org/dev/
... _SourceForge: http://sourceforge.net/tracker/?group_id=3D5470
... _python-dev mailing list:
... _comp.lang.python: =
... _PEP Markup: http://www.python.org/peps/pep-0012.html
... _Docutils: http://docutils.sf.net/
... _reStructuredText: http://docutils.sf.net/rst.html
... _Python Software Foundation: http://python.org/psf/
... _last summary:
... _original text file:
... _archive: http://www.python.org/dev/summary/
... _RSS feed: http://www.python.org/dev/summary/channews.rdf