[Python-Dev] python-dev Summary for 2004-10-16 through 2004-10-31 [draft]

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/

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:
   - `python-dev Summary for 2004-09-16 through 2004-09-30 [draft] <>`__
   - `Magic main functions <>`__
   - `Supporting packages on the command line <>`__

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:
   - `ConfigParser shootout, preliminary entry <>`__
   - `What are the goals for ConfigParser 3000? <>`__

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:
   - `Changing pymalloc behaviour for long running processes <>`__
   - `Re: Python-Dev Digest, Vol 15, Issue 46 <>`__

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 

Contributing threads:
   - `Patches <>`__

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:
   - `SQLite module for Python 2.5 <>`__

Skipped Threads
- Python 2.4b1 on win32 installer bug?
- test_subprocess 2.4b1 fails on FreeBSD 5.2
- adding Py{String|Unicode}_{Lower|Upper} and fixing CreateProcess in 
_subprocess.pyd and PyWin32
- IPv6 bug in 2.3.4??
- logging needs better documentation
- bsddb todo for someone - auto-upgrade db format
- Tests broken on Windows
- import w/options
- Adding a developer
       People are only added as a developer if they ask for it and have shown 
they are going to stick around
- audiotest.au and possible copyright issues?
- Re: [Python-checkins]	python/dist/src/Pythoncompile.c, 2.330, 2.331
- Bug [ 959379 ] Implicit close() should check for errors
- weakref callback vs gc vs threads

More information about the Python-Dev mailing list