[Python-Dev] python-dev Summary for 2004-11-01 through 2004-11-15 [draft]

Brett C. bac at OCF.Berkeley.EDU
Sat Dec 18 06:10:21 CET 2004

Now I am only a month behind.

Won't send this out any earlier than Monday night, but probably won't be until 


Summary Announcements
I am hoping to be caught up with my summary backlog by the end of the month. 
Hear is to hoping.

2.4 released
`Python 2.4`_ has been released!  Read the `What's New`_ for 2.4 to see what 
the major changes are since 2.3 .

.. _Python 2.4: http://www.python.org/2.4/
.. _What's New: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html

Contributed threads:
   - `TRUNK FROZEN for 2.4b2 release from 0000UTC 3rd November (tomorrrow) <>`__
   - `RELEASED Python 2.4, beta 2 <>`__
   - `TRUNK UNFROZEN <>`__

Code coverage of the regression tests
Walter Dörwald has a code coverage tool that runs once a month on Python's 
regression test at http://coverage.livinglogic.de/ .  There was some issue with 
the 'trace' module having partially broken in 2.4 .  The coverage was then run 
using ``Lib/test/regrtest.py -T`` to get more accurate numbers.

Contributing threads:
   - `Code coverage tool updated <>`__

Garbage collecting weakref callbacks
Tim Peters discovered that in 2.4 if a weakref's callback is still reachable 
but the referent and weakref itself are unreachable (Tim's example had an 
instance that contained a weakref to itself) that the callback is not called 
during garbage collection.  This seemed inconsistent since if the weakref in 
Tim's example was replaced with an instance that contained a __del__ method 
that the method would have been called.

Tim would like to clean this up so as to be able to ditch __del__ methods in 
Python 3000.  The idea is that one would register a weakref with a callback for 
an object in itself that would be called when it is garbage collected.  This 
would also negate the need for gc.garbage .

Contributing threads:
   - `weakref gc semantics <>`__
   - `patch-finalizer vs Zope3 <>`__

PEP Watch
`PEP 336`_ introduces the idea of having None be a callable object.  The result 
that calling None would return None itself.

.. _PEP 336: http://www.python.org/peps/pep-0336.html

Contributing threads:
   - `PEP 336, "Make None Callable", by Andrew McClelland <>`__

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 <>`__

2.3 maintenance coming to an end
With Python 2.4 out, maintaining 2.3 is no longer a priority. Anthony Baxter, 
our beloved release manager, has said that 2.3.5 will be most likely coming out 
in January.  After that, though, don't count on another 2.3 release since 2.4 
will take its place as the version to maintain.

All of this came about by the fact that Facundo Batista asked if closing 2.1 
bugs was okay.  As long as they have been fixed in the earliest version being 
maintained, closing them is fine.  This goes for 2.2 as well.  And as soon as 
2.3.5 is out the door will most likely apply to 2.3 bugs.

Contributing threads:
   - `Policy about old Python versions <>`__

Sync/async servers in the stdlib and whether they should be there
There are multiple servers in the core for handling communications in both a 
synchronous and asynchronous manner.  The idea came up of developing an API 
that all servers could follow in the core.  While the discussion went back and 
forth with multiple mentions of PEAK, Twisted, and greenlets_, in the end the 
trend of the discussion suggested doing this well would be very difficult and 
not worth the effort.  asyncore and asynchat also seemed to be deemed worth 
deprecation and thus not worth using.

.. _PEAK: http://peak.telecommunity.com/
.. _Twisted: http://www.twistedmatrix.com/
.. _greenlets: http://codespeak.net/svn/user/arigo/greenlet/

Contributing threads:
   - `Synchronous and Asynchronous servers in the standard library <>`__

Getting the opcode count for rough profile numbers
The idea was proposed of introducing sys.gettickeraccumulation which would 
contain the number of opcodes executed since the interpreter started.  The idea 
is that you can get a rough estimate of how much time is being spent in Python 
code.  The value of this has wavered back and forth with no clear answer.

Contributing threads:
   - `proposal+patch: sys.gettickeraccumulation() <>`__


Having syntactic support for variable-sized unpacking came up again

Contributing threads:
   - `syntactic shortcut - unpack to variably sized list <>`__

Skipped Threads
- Deprecate PyRange_New()
- interlocking dependencies on the path	to a release
       see the first email to see what steps are needed for a release
- Overflow in socketmodule.c?
- Int literals and method calls
       To get access to methods on an int literal put a space after the number; 
``1 .__class__``
- os.access versus os.exist
- syntactic shortcut - unpack to variably sized list
       don't expect syntactic support variable-length sequences ain't happenin'

More information about the Python-Dev mailing list