skip to navigation
skip to content

Help Fund Python

python-dev Summary for 2006-03-16 through 2006-03-31

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-03-16_2006-03-31]

Announcements

Python 2.5 schedule

Python 2.5 is moving forward along its release schedule. A few issues still remain; check PEP 356 for details.

Contributing thread:

Python 3000 gets its own list

Serious work on Python 3000 has started now, with a new python-3000 mailing list for general discussion, and a python-3000-checkins mailing list for checkins to the p3yk branch. Right now, Guido wants patches to focus mainly on ripping out old code (e.g. classic classes) and wants the discussion to focus primarily on formalizing the processes for introducing Python 3000.

Note that processes is what's important right now

Contributing threads:

Buildbot warnings redirected to python-checkins

The buildbot warnings, which for a short time this month appeared on python-dev, have been redirected to the python-checkins list.

Contributing thread:

Checkins that change behavior must be accompanied by tests

Though it's always been good practice to check in a test with any behavior-changing patch, Neal Norwitz has requested extra care in this area as we approach the release of Python 2.5. From this point on, any checkin that could change behavior should be accompanied by a corresponding test.

Contributing thread:

Email 4.0 merged into Python 2.5 trunk

Barry Warsaw has merged the Email 4.0 package into the Python 2.5 trunk. There's a minor incompatibility in that email.Parser is now a placeholder object instead of a module, but this should not affect the vast majority of users.

Contributing thread:

Summaries

Including pysqlite in the stdlib

Anthony Baxter asked if folks were still interested in including pysqlite in Python 2.5 and got a pretty positive response. Gerhard Häring said he could release pysqlite 2.2 and then merge that into Python SVN trunk. In the future, he agreed to synchronize stable changes in the standalone release with the Python core sqlite module. Accompanying these agreements was a long discussion about the pros and cons of including pysqlite, and of course an endless debate about what the new module should be named. In the end, Guido approved the inclusion of pysqlite, and it was given the name sqlite3.

Contributing thread:

Choosing a new tracker system

After Guido noticed that SourceForge had stopped sending him emails when a patch was assigned to him, a number of people took up a discussion about how to replace the SourceForge tracker system. There was already an existing PSF committee in charge of finding such a replacement, and they were considering roundup, trac and jira, though Bugzilla and RT had already been vetoed. There was already an instance of roundup running on python.org, and Python-Hosting and Atlassian had existing offers to host Python on Trac and Jira (respectively). There was some discussion about setting up one of these for Python 3000, but Guido thought it was too early for this.

Getting the data out of SourceForge seemed to be the current sticking point, and so Fredrik Lundh wrote up some tools to do this and posted the results to http://effbot.org/tracker-20060403.zip. The discussion was then moved to the infrastructure list.

Contributing threads:

The C-level set API

Barry Warsaw wanted to add PySet_Clear(), PySet_Update() and PySet_Next() to the C-level set API. Raymond Hettinger objected, saying that this functionality was already available through PyObject_CallMethod(s, "clear", NULL), PyObject_CallMethod(s, "update", "O", iterable) and PyObject_GetIter(s) respectively (with the last being notably safer too). Barry said that he was hoping to get some static compiler checks and easier debugging that would be lost by using PyObject_CallMethod, and to get some speedups over PyObject_GetIter() in the same way that PyDict_Next() had. Eventually, Raymond agreed to adding PySet_Clear() to the public API and to adding _PySet_Next() and _PySet_Update() to the private API.

Contributing threads:

Class decorators

Greg Ewing suggested a use-case for class decorators that could not be easily addressed with metaclasses: adding a class (but not its subclasses) to a registry. After Phillip J. Eby explained the hack that PyProtocols currently uses to make something like class decorators available, Guido suggested that someone write a PEP to add class decorators to Python 2.6. There was some discussion about moving decorators for classes inside the class for readability reasons, but Guido felt like this was too magical. No PEP had yet been produced at the time of this summary.

Contributing thread:

Python 3.0: Exception hierarchy issues

A question from Nick Coghlan about where the new GeneratorExit exception should be placed sparked a new discussion about how the exception hierarchy should look. Barry Warsaw suggested that Exception should be at the top of the hierarchy with KeyboardInterrupt, GeneratorExit, SystemExit, StopIteration, Error and Warning being the next level down. All user defined errors would inherit from Error. People seemed to like this idea, but it would break backwards compatibility as users have been told for a while that their exceptions should derive from Exception, not Error. Guido voted for keeping the PEP 352 semantics (with BaseException at the top of the hierarchy).

Barry promised to address the hierarchy issue again on the Python 3000 list.

Contributing thread:

Python 3.0: Exception statement

Greg Ewing asked if the except clause in Python 3.0 could be changed to:

except <type-or-tuple> as <value>:

instead of the current:

except <type-or-tuple>, <value>:

which can result in confusing behavior when you accidentally write:

except TypeError, ValueError:

and have your TypeError instance bound to the name ValueError. Guido approved the proposal, and then the discussion veered off into the usual syntax debate, this time about whether to use "with" instead, whether to use commas or "or"s between the exception types, and whether or not to require parentheses around multiple types. Guido reiterated his support for the original proposal and shortly afterwards, the thread died.

Contributing thread:

Adding an N-dimensional array interface to Python

Travis E. Oliphant asked about including Numpy's N-dimensional array interface in Python core by adding a __array_struct__ member to array.array that looks like:

typedef struct {
    int version;          /* contains the integer 2 as a sanity check */
    int nd;               /* number of dimensions */
    char typekind;        /* kind in array --- character code of typestr */
    int itemsize;         /* size of each element */
    int flags;            /* flags indicating how the data should be interpreted */
    Py_intptr_t *shape;   /* A length-nd array of shape information */
    Py_intptr_t *strides; /* A length-nd array of stride information */
    void *data;           /* A pointer to the first element of the array */
} PyArrayInterface;

This struct is basically unchanged over Numpy's last 10 years of evolution and Travis was hoping to finally get the interface blessed by official inclusion in Python so that PIL, PyVox, WxPython, PyOpenGL, etc. could all start using the same interface. Guido asked for a PEP, but no one seemed to feel comfortable taking the array interface definition and producing a PEP out of it.

Contributing thread:

Inconsistent behavior between += and .__iadd__()

Travis Oliphant noticed that a.__iadd__(b) and a += b currently do different things depending on the type of their arguments:

a = range(5)
b = numpy.arange(5)
a.__iadd__(b)
assert a == [0, 1, 2, 3, 4, 0, 1, 2, 3, 4]

a = range(5)
b = numpy.arange(5)
a += b
assert a == numpy.array([0, 2, 4, 6, 8])

This apparently occurs because PyNumber_InPlaceAdd coerces a into a numeric type (a numpy.array object) before trying PySequence_InPlaceConcat. Guido suggested that += (and *=) should check both the numeric and sequence slots before trying to coerce either arguments. Armin Rigo pointed out that this fix would require that listobject.__add__(intobject) would have to return NotImplemented instead of immediately raising an exception, but promised to provide the fix when he could.

Contributing thread:

Supported platforms

A couple different threads asked about which of the lesser-known platforms Python is supported on. Andrew MacIntyre verified that OS/2 is still being supported, Donn Cave and Francois Revol maintain the BeOS (a.k.a. Zeta OS) port, and Ralf W. Grosse-Kunstleve promised to make Tru64 machines available for testing Python if people needed them.

Contributing threads:

Definition of sys.executable

Fredrik Lundh pointed out that when Python is embedded, the documentation for sys.executable seems suggest that it should be pointed to the executable used to start the program, not Python itself. Since this executable is no longer Python, you can no longer run sys.executable to start another Python instance. At least py2exe and PyXPCOM both depend on the current behavior, so the implementation can't be changed. Fredrik suggested adding sys.python_executable so that Python code would always be able to start another Python instance, even when embedded, but the discussion concluded without any final decisions.

Contributing thread:

Location of modules for multi-architecture platforms

Neal Becker reported that on x86_64, the Twisted package gets split between an architecture independent directory and an architecture dependent one, and so when Python searches for the package, it finds only the first part of the installation. There was then some discussion about how multi-architecture platforms should be properly supported. The conclusion seemed to be that the package should not be split; instead two versions of the package, one for each architecture, should be installed to two different directories. But Martin v. Löwis indicated that if anyone thought they knew better how this should work, he would accept patches.

Contributing thread:

PEP 299: rejected

Guido rejected PEP 299, which would have encouraged the definition of a module-level __main__() function instead of the current:

if __name__ == '__main__':
    ...

The rejection came after it was clear that writing code to work both before and after the PEP was going to be difficult, that import __main__ would have started raising TypeErrors, and that the proposal didn't particularly gain much over the status quo.

Contributing thread:

String exceptions in generator.throw()

In its implementation at the time, PEP 342's throw method on generators did not support string exceptions. Phillip J. Eby wanted to add support for them, but suggested that string exceptions only be allowed if accompanied by a traceback so that string exceptions could only be passed on, not created. Guido indicated that he'd rather keep things simple and just allow string exceptions regardless of the presence of a traceback.

Contributing thread:

Generator memory leaks

With PEP 342, generators need a __del__ method to raise the GeneratorExit exception in active generators. However, the __del__ method also means the generator cannot be cleaned up when it's part of a reference cycle. Tim Peters suggested that the best solution was simply to add a special test for generators, and leave any generalizations of this idea until they're actually needed.

Contributing threads:

PyMem and PyObject freeing mismatches

When Python's small-object memory allocator was introduced, Python originally supported obtaining an object through PyObject_{New,NEW} and freeing it using any one of PyObject_{Free,FREE}, PyMem_{Del,DEL} or PyMem_{Free,FREE}. The hacks to support the mismatched (PyMem_*) frees were pretty horrible, and since using such mismatched calls has been forbidden for years, Tim Peters started ripping out the support code. Turns out that Python core itself had a number of mismatched calls, but Tim decided to leave the change checked in so that these kinds of issues could get fixed before the 2.5 release. Adam DePrince promised to provide a patch to identify in a debug-build when an object was freed with a mismatched call.

Contributing thread:

Skipped Threads

Epilogue

This is a summary of traffic on the python-dev mailing list from March 16, 2006 through March 31, 2006. 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 python-dev summary is the 1st written by the python-dev summary slave, Steve Bethard (Looks like I'm on my own now!).

To contact me, please send email:

  • Steve Bethard (steven.bethard at gmail.com)

Do not post to comp.lang.python if you wish to reach me.

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 cent counts 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@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.