[Python-Dev] python-dev Summary for 2004-10-16 through 2004-10-31 [draft] (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Sun Dec 12 04:10:09 CET 2004

Winter Break is upon me which means I have time to catch up on the Summaries. I will definitely be caught up by the end of the month.

As for this summary, I will send this out around Wednesday. As always corrections are appreciated. If you feel one of the skipped threads deserves coverage please feel free to write up a summary and I will edit it and include it.

===================== Summary Announcements

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.

.. _Python 2.4: http://www.python.org/2.4/

========= Summaries

Specifying main functions and calling packages with '-m'

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. A PEP is on the way, though. Until then, you can use Nick Coghlan's recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307772.

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'. But the discussion never went any farther. This will require a PEP to ever even be seriously considered.

Contributing threads:

ConfigParser shootout begins

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 .

Contributing threads:

Making pymalloc friendlier to long running processes

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.

Contributing threads:

How to get a patch looked at

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:

  1. Review 10 other patches on SF
  2. Send an email to python-dev listing the 10 patches that you reviewed and the one patch you want to be reviewed
  3. Your specific patch gets reviewed by Martin

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.

Contributing threads:

Discussion of including pysqlite in the stdlib

The idea of including pysqlite_ in the stdlib came up once again (not this is the wrapper for SQLite_ and not SQLite itself). The arguments for including the module were the SQLite is most likely used more than Sleepycat and thus deserved a place in the stdlib if bsddb did. It also goes along with Python's idea of "batteries included".

Arguments against started with the idea of sanctioning pysqlite over other SQLite wrappers did not seem proper. People also thought that including bsddb might not be correct anymore and thus should not be used as a basis for including pysqlite.

This all then led into a discussion about package management and how to simplify extending what can be installed at compile-time. The idea of pushing PyPI_ came up as well as revising PEP 206_.

.. _pysqlite: http://pysqlite.org/ .. _SQLite: http://www.sqlite.org/ .. _PyPI: http://www.python.org/pypi .. _PEP 206: http://www.python.org/peps/pep-0206.html

Contributing threads:

=============== Skipped Threads

they are going to stick around

More information about the Python-Dev mailing list