Python 2.5a1 Released

Python 2.5 alpha 1 was released on April 5th. Please download it and try it out, particularly if you are an extension writer or you embed Python -- you may want to change things to support 64-bit sequences, and if you have been using mismatched PyMem_* and PyObject_* allocation calls, you will need to fix these as well.

Contributing threads:

• TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
• outstanding items for 2.5
• chilling svn for 2.5a1
• Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
• RELEASED Python 2.5 (alpha 1)
• TRUNK is UNFROZEN
• segfault (double free?) when '''-string crosses line
• pdb segfaults in 2.5 trunk?
• IMPORTANT 2.5 API changes for C Extension Modules and Embedders

Contributor agreements

If you're listed in the Python acknowledgments, and you haven't signed a contributor agreement, please submit one as soon as possible. Note that this includes even the folks that have been around forever -- the PSF would like to be as careful as possible on this one.

Contributing threads:

• PSF Contributor Agreement for pysqlite

Firefox Python bug searches

Anthony Baxter has created a Firefox searchbar for finding Python bugs by their SourceForge IDs. There are also two Firefox sidebar options: Mark Hammond's and Daniel Lundin's.

Contributing thread:

• Firefox searchbar engine for Python bugs

Building Python with the free MS Toolkit compiler

Paul Moore documented how to build Python on Windows with the free MS Toolkit C++ compiler on the wiki. The most up-to-date version of these instructions is in PCbuild/readme.txt.

Contributing thread:

• Building Python with the free MS Toolkit compiler

Please login to the wiki when you make changes

Skip Montanaro has requested that anyone posting to the wiki sign in first, as this makes things easier for those monitoring changes to the wiki. When you're logged in, your changes appear with your name, and so can be immediately recognized as not being wiki-spam.

Contributing thread:

• Suggestion: Please login to wiki when you make changes

Checking an older blamelist

While the buildbot blamelist may scroll off the main page in a matter of hours, you can still see the blamelist for a particular revision by checking a particular build number, e.g. to see build 800 of the trunk on the G4 OSX, you could check http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/800.

Contributing threads:

• Preserving the blamelist
• TODO Wiki (was: Preserving the blamelist)

Garbage collection issues

One of the problems with garbage-collecting generators (now that they have a __del__ method) was that GC normally assumes that because the type has a __del__ method, the instance needs finalization. Many generator instances may not need finalization even though their type has a __del__ slot, so generators have been special-cased in the garbage-collection code so that GC can sometimes tell that a generator does not need its finalizer called.

As a side note, Tim Peters pointed out that if you're worried about cyclic-gc and __del__ methods, one of the ways to avoid problems is to remove the __del__ method from the object you think might be included in a cycle, and add an attribute to that object that holds a "closing" object with a __del__ method that simply closes all your resources. Since your main object won't have a __del__, it will be easily collected, which should make the closing object collectable too.

Contributing threads:

• reference leaks, __del__, and annotations
• reference leaks, __del__, and annotations
• Debugging opportunity :-)

ElementTree naming

The elementtree package was included in Python 2.5 as xml.etree. There were some complaints about the naming schemes (which aren't quite PEP 8-compliant) but changing these while elementtree is still distributed as a standalone package seemed like a bad idea. People generally felt that style-motivated renamings should all wait until Python 3000.

Contributing thread:

• elementtree in stdlib

Externally maintained modules

Brett Cannon was putting together a PEP for externally maintained code in the stdlib (e.g. ctypes and pysqlite). The PEP will list all modules and packages within the stdlib that are maintained externally, as well as the contact info for their maintainers and the locations where bugs and patches should be reported. At the time of this summary, he had not yet been assigned a PEP number.

Contributing threads:

• PEP to list externally maintained modules and where to report bugs?
• need info for externally maintained modules PEP

String prefix for internationalization

Martin Blais proposed an i prefix for internationalized strings to get rid of the _() required by pygettext. This would allow pygettext to more easily identify internationalized strings, and reduce the number of parentheses necessary in internationalized code. However, it would only have saved two key-strokes, it would have required the introduction of iu and ir prefixes, and it would have forced some rewriting of the tools that currently do string extraction using _(), so the idea was rejected.

Contributing thread:

• The "i" string-prefix: I18n'ed strings

PEP 359: The make statement

Steven Bethard introduced a PEP for the make statement which would have made the statement:

make <callable> <name> <tuple>:
    <block>

syntactic sugar for:

class <name> <tuple>:
    __metaclass__ = <callable>
    <block>

The goal was to allow the creation of non-class objects from a namespace without requiring a misleading class statement and __metaclass__ hook. With appropriately defined objects, the make statement would have supported syntax like:

make block_property x:
    '''The x of the frobulation'''
    def fget(self):
        ...
    def fset(self):
        ...

make Schema registration:
    make String name:
        max_length = 100
        not_empty = True
    make PostalCode postal_code:
        not_empty = True
    make Int age:
        min = 18

In current Python these would have to be created using class statements which misleadingly created objects that were not classes. Responses were mixed, and the discussion continued on into the next fortnight.

Contributing thread:

• PEP 359: The "make" Statement

Formatting exceptions with their module names

Georg Brandl checked in a patch to make traceback.format_exception_only() prepend the exception's module name in the same way the interpreter does. This caused a number of doctests to fail because the exception module names were not included. After some discussion, it seemed like people agreed that even though some doctests would be broken, it was more important to have the interpreter and traceback.format_exception_only() produce the same output.

Contributing thread:

• [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

Benchmarking python

Benji York and a few others ran Python 2.5a1 through pystone and found it mostly comparable to 2.4.2. However, Raymond Hettinger pointed out that pystone isn't really an appropriate benchmark for comparing across versions -- it's intended more for comparing across architectures and compilers.

Contributing threads:

• 2.5a1 Performance
• Buildbot slave locks (Was: 2.5a1 Performance)

PySocketSockObject, socketmodule.c, _ssl.c and Windows

Tim Peters noticed that on Windows, socketmodule.c and _ssl.c disagreed about the offset of the sock_timeout member of a PySocketSockObject. Turns out that since _socket was built by a .vcproj but _ssl was built by _ssl.mak (which had forgotten to define WIN32), doubles were aligned to an 8-byte boundary when socketmodule.c was compiled but a 4-byte boundary when _ssl was compiled.

Contributing thread:

• Who understands _ssl.c on Windows?

Getting a dictionary of counts

Alex Martelli proposed adding a tally() function to the collections module which would count the number of each value in an iterable and produce a dictionary. So for example:

tally('abacaab') == {'a': 4, 'c': 1, 'b': 2}

People generally thought the function would be useful, but there was some discussion as to whether or not it would be better to provide a collections.bag object instead. The discussion fizzled out without any patches being produced.

Contributing thread:

• tally (and other accumulators)

Building Python with C++

Anthony Baxter has donated some of his recent time to getting Python to compile with g++. He got Python core to compile correctly, but there were lots of errors in the Modules code that wasn't C++ safe. If you'd like to help Anthony out and fix some bugs, try it yourself using CC=g++ ./configure --with-cxx=g++

Contributing thread:

• building with C++

Adding PEP 302 support

Phillip J. Eby has been working on adding PEP 302 import loader support to the necessary modules around Python. In the process, he noticed that both runpy and test.test_importhooks reimplement the base PEP 302 algorithm, and suggested adding functions to pkgutil that would allow such modules to all share the same code for this kind of thing. The code appears to have been checked in, but docs do not appear to be available yet.

Contributing threads:

• PEP 302 support for traceback, inspect, site, warnings, doctest, and linecache
• Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil'
• PEP 302 support for pydoc, runpy, etc.

Having Python use dlopen() on Darwin/OS X

Zachary Pincus asked about using the normal code path for Unix-like systems through dlopen() for Darwin/OS X instead of the officially discouraged NeXT-derived APIs that Python was using at the time. Bob Ippolito approved the patch, and OS X users should hopefully see the change in Python 2.5.

Contributing thread:

• Use dlopen() on Darwin/OS X to load extensions?

Saving the hash value of tuples

Noam Raphael suggested caching the hash value of tuples in a similar way to what is done for strings now. But without any measurements showing that this improved performance, and with the relative rareness of hashing tuples, Guido thought that this was a bad idea.

Contributing thread:

• Saving the hash value of tuples

sqlite3.dll issues

If a Windows user tries import sqlite3 and Python finds SQLite's sqlite3.dll before it finds pysqlite's sqlite.py module, Python will end up incorrectly raising an ImportError. Martin v. Löwis suggested that maybe Python should stop treating .dll files as extension modules so conflicts like this could be avoided. It was unclear at the end of the thread if this (or any other) route was being persued.

Contributing thread:

• Renaming sqlite3

New Python icons

Andrew Clover made some new Python icons available based on the logo on the new website. People on python-dev really liked them, and it looked like they'd probably make it into Python 2.5.

Contributing threads:

• New-style icons, .desktop file
• New-style icons, .desktop file

Py_Initialize/Py_Finalize leaking memory

Martin v. Löwis corrected some documentation errors that claimed that Py_Finalize would release all memory (it can't be guaranteed to do so). In the process, Martin and Tim Peters discussed a recent bug where running Py_Initialize/Py_Finalize in a loop left more and more objects behind each time. The hope was to get the number of added objects after a Py_Initialize/Py_Finalize pair back down to zero if possible, and Martin found at least one leak, but it was unclear at the end of the thread how close they had gotten.

Contributing thread:

• Py_Finalize does not release all memory, not even closely

Removing PyObject_REPR

Thomas Wouters noticed that the PyObject_REPR() macro, which was originally introduced as an internal debugging API, leaks a PyString object. It looked like the macro would either be removed entirely, or redefined to call Py_DECREF appropriately and return a newly allocated (and thus freeable) string.

Contributing thread:

• PyObject_REPR()

uriparse module to replace urlparse module

Paul Jimenez offered up his uriparse module which improves on urlparse. Currently, urlparse doesn't comply with STD66 (a.k.a. RFC3986), as it hard-codes some URI schemes instead of applying the same syntax to all of them. Martin v. Löwis asked for more documentation, and John J Lee suggested deprecating a few functions from urllib and putting RFC-compliant versions in uriparse. The discussion then moved to the tracker, but at the time of this summary, the remaining issues had not yet been resolved.

Contributing thread:

• New uriparse.py

Line numbers with the new AST compiler

Jeremy Hylton noticed that with the new AST-based compiler, the line numbers for things like the implicit return None at the end of a function were occasionally different from previous versions of Python. The changes looked harmless, so Guido said it was fine to leave the code as it was. Jeremy promised to look into some of the other special cases for alpha 2.

Contributing thread:

• line numbers, pass statements, implicit returns

Commenting on Topics

To comment on anything mentioned here, just post to comp.lang.python (or email python-list@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

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.