This is a summary of traffic on the python-dev mailing list from July 01, 2004 through July 15, 2004. It is intended to inform the wider Python community of on-going developments on the list. 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!
This is the forty-forth summary written by Brett Cannon (wished he could be at OSCON to see Guido throw a pie).
To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there.
All summaries are archived at http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for PEP markup and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot 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.
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 on 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.
The Python Software Foundation is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps.
I don't think my informal editors on python-dev often enough for their help. In case you didn't know, I send a rough draft (read: first draft since I hate proof-reading) to python-dev before a summary out for general consumption to make sure I didn't totally get something wrong. Luckily I tend not to screw stuff up that badly and it ends up being little grammatical errors here and there. But if it wasn't for them the summaries would not be the level of quality that they are (read: wouldn't seem like they are written by some grad student with impeccable grammar but instead as if they are written by some grad student with decent grammar =). Anyway, I just felt like I should give a public thanks to everyone who has ever sent me a fix.
And it looks like Unicode will finally work in the Summaries! Thanks for that goes to David Goodger for making that happen.
Thanks to Anthony Baxter, Python 2.4a1 went out the door in early July. If you have not downloaded it and run the regression test suite, please do (see the stdlib docs on the 'test' pacakge on how to run the tests and please check if you can that any failures you got were not already posted and possibly fixed in CVS).
Some discussion on Martin v. L÷wis' MSI installer code took place on the list. It seemed like Martin's installer was good and just needed some docs.
Since the Decimal package went in at the beginning of July, most of the discussions about Decimal revolved around making it easy to use out of the box for normal folk; "practicality beats purity".
First discussion was over invalid constructor arguments. Originally if you tried something like Decimal("Raymond"), it would return NaN. Obviously that ain't cool. Turned out to be a misinterpretation of the IBM spec that Decimal is based on. In the doc an exception being "signaled" is the same as it being raised in Python. So that got clarified and now raises an exception.
From there a discussion of what signals should be on by default ensued. Michael Chermside sparked it with his list of what he thought would work. Some other people posted theirs and all of them coagulated into a final list. Those defaults have been added to CVS and will be available in 2.4a2 .
AM Kuchling organized another Python Bug Day on July 10. A couple of people, including yours truly, showed up on #python-dev and managed to close a bunch of patches and bugs; 18 and 15 of them to be exact. Thanks to all that helped out, it was fun.
The next one is tentatively scheduled for August 7th.
Guido had noticed someone had committed a patch that changed open() to file(). While some of us thought that using the file type's factory constructor was the proper way to open files, Guido set us straight. Turns out he wants open() to be used for opening files. Part of the reason is that open() might at some point develop the abilities to open other things such as URLs (think open on OS X).
Michael Chermside wondered the same thing. Tim Peters answered. Turns out to be undefined, but currently implemented as to keep the original key and not the new key.
Jim Fulton added a new macro named Py_CLEAR() that takes in a variable, Py_DECREFs it, and then sets it to NULL. The common use case is a field in a struct that can hold a PyObject but not always which is set to NULL when it doesn't. It is in no way meant to signify the PyObject should be garbage collected immediately, just that the current variable no longer holds a reference to anything.
Result: can be faster, but people don't want the added complexity (and Guido had a bad experience while developing the ABC language).
For those of you who don't know what tagged integers are, imagine all PyObjects being either an object or integer based on whether certain bits were flipped. This has the perk of saving space and not having to do a memory fetch to get to the int value in an int object. Problem is you now have to check constantly whether a PyObject is really a pointer or a tagged integer.
If you know what proper tail recursion is, skip this paragraph. Still there? OK, on with the lesson. Proper tail recursion is when a recursive call is made in which the callee does not need to return to the caller. Think of a 'return' statement that makes a recursive function call only; you don't have to return through the call chain since you just want that return statement to get to the first point where you are going to perform calculations on it. So if you have a recursive 'return' statement you can skip creating a bunch of frames that stick around by just having each subsequent tail recursive call just return to the beginning of the recursion. Confused yet? Use Scheme and you will know what I am talking about (this stuff is actually required by the Scheme specification). I could explain it using continuations, but chances are more people know about tail recursion than continuations so I am not even go to bother melting your brains with continuations. =)
A patch to add proper tail recursion optimization was proposed, but Guido shot it down very strongly. Guido has spoken and is not about to change his mind. If you want to read the long thread on why then go ahead. Basically, though, Guido said that if you are writing recursive code that is hitting the recursion limit you should probably change your algorithm. There was also issues with how to handle tracebacks but that wasn't as entertaining. =)