QOTF

We have our first ever Quote of the Fortnight (QOTF), thanks to the wave of discussion over PEP 343 and Jack Diederich:

I still haven't gotten used to Guido's heart-attack inducing early enthusiasm for strange things followed later by a simple proclamation I like. Some day I'll learn that the sound of fingernails on the chalkboard is frequently followed by candy for the whole class.

See, even threads about anonymous block statements can end happily! ;)

Contributing thread:

• PEP 343 - Abstract Block Redux

[SJB]

First PyPy Release

The first release of PyPy, the Python implementation of Python, is finally available. The PyPy team has made impressive progress, and the current release of PyPy now passes around 90% of the Python language regression tests that do not depend deeply on C-extensions. The PyPy interpreter still runs on top of a CPython interpreter though, so it is still quite slow due to the double-interpretation penalty.

Contributing thread:

• First PyPy (preview) release

[SJB]

Thesis: Type Inference in Python

Brett C. successfully defended his masters thesis Localized Type Inference of Atomic Types in Python, which investigates some of the issues of applying type inference to the current Python language, as well as to the Python language augmented with type annotations. Congrats Brett!

Contributing thread:

• Localized Type Inference of Atomic Types in Python

[SJB]

PEP 343 and With Statements

The discussion on "anonymous block statements" brought itself closer to a real conclusion this fortnight, with the discussion around PEP 343 and PEP 3XX converging not only on the semantics for "with statements", but also on semantics for using generators as with-statement templates.

To aid in the adaptation of generators to with-statements, Guido proposed adding close() and throw() methods to generator objects, similar to the ones suggested by PEP 325 and PEP 288. The throw() method would cause an exception to be raised at the point where the generator is currently suspended, and the close() method would use throw() to signal the generator to clean itself up by raising a GeneratorExit exception.

People seemed generally happy with this proposal and -- believe it or not -- we actually went an entire eight days without an email about anonymous block statements!! It looked as if an updated PEP 343, including the new generator functionality, would be coming early the next month. So stay tuned. ;)

Contributing threads:

• PEP 343 - Abstract Block Redux
• Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
• Example for PEP 343
• Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
• PEP 343 - New kind of yield statement?
• PEP 342/343 status?
• PEP 346: User defined statements (formerly known as PEP 3XX)

[SJB]

Decimal FAQ

Raymond Hettinger suggested that a decimal FAQ would shorten the module's learning curve, and drafted one. There were no objections, but few adjustments (to the list, at least). Raymond will probably make the FAQ available at some point.

Contributing thread:

• Decimal FAQ

[TAM]

Constructing Decimals

A long discussion took place regarding whether the decimal constructor should or should not respect context settings, and whether matching the standard (and what the standard says) should be a priority. Raymond Hettinger took the lead in the status-quo (does not) corner, with Tim Peters leading the opposition. Tim and Guido eventually called in the standard's expert, Mike Cowlishaw. He gave a very thorough explanation of the history behind his decisions in this matter, and eventually weighed in on Raymond's side. As such, it seems that the status-quo has won (not that it was a competition, of course <wink>).

For those that need to know, the unary plus operation, as strange as it looks, forces a rounding using the current context. As such, context-aware construction can be written:

val = +Decimal(string_repr)

Contributing threads:

• Adventures with Decimal
• Decimal construction
• [Python-checkins] python/nondist/peps pep-0343.txt, 1.8, 1.9

[TAM]

Handling old bug reports

Facundo Batista continued with his progress checking the open bug reports, looking for bugs that are specific to 2.2.1 or 2.2.2. The aim is to verify whether these bugs exist in current CVS, or are old-of-date. There are no longer any bugs in the 2.1.x or 2.2.x categories, and Facundo wondered whether removing those categories would be a good idea. The consensus was that there was no harm in leaving the categories there, but that changing the text to indicate that those versions are unmaintained would be a good idea.

Raymond Hettinger reminded us that care needs to be taken in closing old bug reports. Particularly, a bug report should only be closed if (a) there are no means of reproducing the error, (b) it is impossible to tell what the poster meant, and they are no longer contactable, or (c) the bug is no longer present in current CVS.

Contributing threads:

• Deprecating old bugs, now from 2.2.2
• Closing old bugs
• Old Python version categories in Bug Tracker

[TAM]

Exception chaining

Ka-Ping Yee has submitted PEP 344, which is a concrete proposal for exception chaining. It proposes three standard attributes on trackback objects: __context__ for implicit chaining, __cause__ for explicit chaining, and __traceback__ to point to the traceback. Guido likes the motivation and rationale, but feels that the specification needs more work. A lot of discussion about the specifics of the PEP took place, and Ka-Ping is working these into a revised version.

One of the major questions was whether there is no need for both __context__ and __cause__ (to differentiate between explicit and implicit chaining). Guido didn't feel that there was, but others disagreed.

Discussion branched off into whether which attributes should be double-underscored, or not. Guido's opinion is that it depends who "owns" the namespace, and with "magic" behaviour caused (or indicated) by the presence of the attribute. He felt that the underscores in the proposed exception attributes should remain.

Contributing threads:

• PEP 344: Exception Chaining and Embedded Tracebacks
• PEP 344: Implicit Chaining Semantics
• PEP 344: Explicit vs. Implicit Chaining
• Tidier Exceptions

[TAM]

Adding content to exception messages

Nicolas Fleury suggested that there should be a standard method of adding information to an existing exception (to re-raise it). Nick Coghlan suggested that this would be reasonably simple to do with PEP 344, if all exceptions were also new-style classes, but Nicolas indicated that this wouldn't work in some cases.

Contributing threads:

• Adding content to exception messages

[TAM]

Introduction

This is a summary of traffic on the python-dev mailing list from May 16, 2005 through May 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 fourth 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.