Giving myself a gold watch

As some of you may have already heard or read, I am retiring from writing the python-dev Summaries after sending out the March 16 - 31 summary. It has been a long time coming and it required a kick in the ass (graciously supplied by Steve Holden) to finally make me let go of doing this and let someone else take over.

The joy of the Summaries has dwindled over the 2.5 years I have been doing this. I was only doing them to be helpful. But now I would rather put my time and effort I have for Python into coding work rather than the Summaries. I would like to think I can be more productive and helpful as a programmer than a writer. And so there will only be three more regular Summaries after this written by yours truly.

But do not worry about the Summaries dying! When I announced this (see http://mail.python.org/pipermail/python-dev/2005-March/051823.html for the thread that led to this), three individuals stepped forward to pick up the work once I step down. Steven Bethard, Tony Meyer, and Tim Lesher are being considered for picking up where I left off. There is the possibility that they will actually write the Summaries together as a team.

As for my last Summary, expect a more expository one with my random thoughts on PyCon, Python, and anything else that comes to mind that I feel like using this space to abuse. You have Scott David Daniels to thank for that format idea for my final hurrah.

Go to PyCon!

I just booked my hotel room for PyCon. You going to be there so I can shake your hand, thanking you for supporting Python?

Python Security Response Team founded

For those of you who don't know, a security hole was found in XML-RPC servers in the stdlib that use register_instance; details at http://www.python.org/security/PSF-2005-001/ .

In response to this, Guido has now formed the 'Python Security Response Team`_. This group's job is to respond to any and all security issues that come up as quickly as possible and to issue a patch in a timely fashion.

Contributing threads:

• Wanted: members for Python Security Response Team

Licensing issues in the stdlib

It was reported to python-dev that 'profiler' and 'md5 do not conform to the Debian Free Software Guidelines. The specific issue was derived works using Python. This is obviously not a good thing.

Things are in the works, though. The hope is to get the copyrights signed over and all of this cleared up. At worst the modules will be replaced with code licensed to the Python Software Foundation. If you care to accelerate this by writing replacements please do so.

Contributing threads:

• license issues with profiler.py and md5.h/md5c.c

Replacing list of constants with tuple of constants

note: written by Tim Lesher

Skip Montanaro noticed that Raymond Hettinger had made a number of library checkins replacing lists with tuples in constructs like for a in [1, 2, 3]: and if a in [1, 2, 3]:. He agreed with the motivation (the peephole optimizer can convert a tuple of constants into a single constant, eliminating construction time), but questioned hardcoding the optimization. Instead, he suggested teaching the optimizer about "throwaway" lists in for and if statements.

Guido agreed with the sentiment. Raymond accepted the suggestion, and checked in code to implement it. There were some issues, though, but those will be covered in the next Summary.

Contributing threads:

• list of constants -> tuple of constants

Complex I/O problem

note: written by Tim Lesher

Neal Becker asked why the result of printing a complex number is not an acceptable input to constructing a complex. For example, print complex(2,2) yields '(2+2j)'; but complex('(2+2j)') throws a ValueError.

A. M. Kuchling responded that many types, including 'str' and 'file' share this behavior, and that in any event, parsing string representations is a job more suited to 'eval' than to classes themselves.

Guido reiterated the rules for str() (used by 'print') and repr(). Since both complex.__str__ and complex.__repr__ pass the eval() test, he pronounced it fine.

Contributing threads:

• complex I/O problem

2.3.5 and 2.4.1 release plans

note: written by Steve Bethard

Anthony Baxter, Alex Martelli and Tim Peters squelched a bug where deepcopy failed on instances of types that lacked an __mro__ attribute.

The patch was pretty straight-forward (use inspect.getmro instead of cls.__mro__), but coming up with a test case was hard -- creating a Python object that doesn't have an __mro__ takes some complicated C code like that of Zope's ExtensionClass. Fortunately, John Lenton's c.l.py suggestion to simply raise an AttributeError for __mro__ in __getattribute__ properly tickled the bug, and 2.3.5 was cleared for release.

Contributing Threads: - 2.3.5 and 2.4.1 release plans

Clarification sought about including a multidimensional array object into Python core

note: written by Steve Bethard

Travis Oliphant and others looked into the issues of including an array object (like that of Numeric or numarray) in Python core.

Guido seemed hesitant, concerned that as Numeric and numarray continue to co-exist, the array object wouldn't be the "best of breed" (one of the requirements for inclusion in Python core). Travis explained that most of the disagreements are over ufunc objects, not the basic array object itself, so it wouldn't be unreasonable to include the array object without the ufunc object if necessary. There was also some suggestion that, at least for basic arithmetic operations, Numeric and numarray mostly agree, so a stripped-down ufunc object for these operations might also be inclusion-worthy.

In an aside that grew decidedly un-aside-ish, Paul F. Dubois, Guido and David Ascher explained why matrix should not inherit from arrayobject -- this would complicate __new__ and cause confusion when mixed operands (arrays and matrices) are given to a binary op like multiplication.

Contributing Threads:

• Clarification sought about including a multidimensional array object into Python core
• Numeric life as I see it

More licensing issues - redistribution

note:: written by Tony Meyer

As most people know, one of the major changes between the Windows builds of Python 2.3 and 2.4 is that 2.4 is built with VC7, rather than VC6. One of the consequences of this change is that 2.4 links with the Microsoft DLL msvcr71.dll, which only some people have, rather than msvcr.dll, which pretty much all Windows users have.

The Windows Python 2.4 distribution installs msvcr71.dll, so it's there when needed. However, those building frozen applications (e.g. with py2exe) need to ensure that their users have msvcr71.dll.

After going through the EULA's for both the commercial and free-to-use Microsoft compilers, it seems that redistributing mscvr71.dll is acceptable, if the re-distributor owns a copy of the commercial (not free) compiler, includes an EULA agreement in one of various forms (e.g. 'click-wrap'), and follows various other minor conditions (note that just about every message in this thread contains "IANAL, but").

This leaves those without VC7 unable to redistribute msvcr71.dll, unless, as some suggested, distributing a frozen Python application can be considered as redistributing Python (and the various other minor conditions are followed).

In an interesting twist, it appears that the official Windows Python 2.4 distribution is in breach of the EULA, as a 'click-wrap' license is required, and is not present. This element of the thread died without reaching a conclusion, however.

If you are a lawyer (with expertise in this area), and would like to comment, then please do!

Contributing threads:

• Is msvcr71.dll re-redistributable?

Avoiding signs in memory addresses

note:: written by Tony Meyer

Troels Walsted Hansen pointed out that builtin_id() can return a negative number in Python 2.4 (and can generate a warning in 2.3). Some 2.3 modules (but no 2.4 ones) have code to work around this, but Troels suggested that a better solution would be to simply have builtin_id() return an unsigned long integer. The consensus was that this would be a good idea, although nothing has been checked in yet, and so this will probably stagnate without someone submitting a patch (or at least a bug report).

Contributing threads:

• builtin_id() returns negative numbers

Introduction

This is a summary of traffic on the python-dev mailing list from February 01, 2005 through February 14, 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 fifty-eighth summary written by Brett Cannon (3 more after this one).

To contact me, please send email to brett at python.org. 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 penny helps so even a small donation with a credit card, check, or by PayPal helps.

If you are looking for a way to expand your knowledge of Python's development and inner-workings, consider writing the python-dev Summaries yourself! I am willing to hand over the reins to someone who is willing to do a comparable or better job of writing the Summaries. If you are interested, please email me at brett at python.org.

Commenting on Topics

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