This is a summary of traffic on the python-dev mailing list from October 16, 2004 through October 31, 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 fifty-first summary written by Brett Cannon (I will be caught up on summaries soon).
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.
Python 2.4 final is now out!
As I mentioned in the last summary my school schedule this past quarter has been insane. But now I am on Winter Break and will hopefully be able to catch up on my Summary backlog.
In my opinion, the new '-m' command line option in Python 2.4 is really handy. But wouldn't it be even handier if you could execute modules in a package? That exact question came up. The reason this kind of thing didn't just go directly into 2.4 was that the semantics are not as obvious nor is it as simple. PEP 338 goes over all of this and also points to a recipe that implements it all now.
This also brought up the discussion of being able to specify a 'main' function to take the place of the good old if __name__ == "__main__" idiom. Some liked the idea of allowing one to define a function named 'main', others '__main__'. PEP 299 discusses all of this.
As mentioned in the last summary, a desire for a replacement for ConfigParser has come into being. It seems the ideas are being hashed out in the wiki at http://www.python.org/moin/ConfigParserShootout .
Pymalloc, when a small chunk of memory is requested that is less than 256 bytes, fetches the memory from a pool of previously used memory that is now available. While this speeds up memory allocation since it does not directly involve calling the OS to free up the memory, it does cause issues for long running processes that have at some point requested a large portion of memory. The example in the OP for this whole topic was an app that needs 1GB for about five minutes, but the amount of allocated memory stays at 1 GB since pymalloc does not free it to the OS.
This was brought up back in June and is summarized at http://www.python.org/dev/summary/2004-06-01_2004-06-15.html#id17 .
No code has been checked in at the moment to change the behavior partially thanks to the difficulty of the problem.
Often times people have a specific patch that they want reviewed/applied to solve a specific problem they are having. Unfortunately the Python developers have limited time; we just can't get to every patch there in a timely fashion. This can be a problem who really need to get a patch in.
Enter Martin v. L÷wis and his deal to review a specific patch:
You can see the exact details of Martin's requirements at http://mail.python.org/pipermail/python-dev/2004-October/049495.html and can also read http://www.python.org/dev/dev_intro.html for ideas on what to do for reviewing.