S
steven.bethard
python-dev Summary for 2006-09-01 through 2006-09-15
++++++++++++++++++++++++++++++++++++++++++++++++++++
... contents::
[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2006-09-01_2006-09-15]
=============
Announcements
=============
----------------------------
QOTF: Quote of the Fortnight
----------------------------
Through a cross-posting slip-up, Jean-Paul Calderone managed to provide us with some inspiring thoughts on mailing-list archives:
One could just as easily ask why no one bothers to read mailing list
archives to see if their question has been answered before.
No one will ever know, it is just one of the mysteries of the universe.
Contributing thread:
- `[Twisted-Python] Newbie question <http://mail.python.org/pipermail/python-dev/2006-September/068682.html>`__
-------------------------
Monthly Arlington sprints
-------------------------
Jeffrey Elkner has arranged for monthly Arlington Python sprints. See the `Arlington sprint wiki`_ for more details.
... _Arlington sprint wiki: http://wiki.python.org/moin/ArlingtonSprint
Contributing thread:
- `Arlington sprints to occur monthly <http://mail.python.org/pipermail/python-dev/2006-September/068688.html>`__
=========
Summaries
=========
-----------------------------------------
Signals, threads and blocking C functions
-----------------------------------------
Gustavo Carneiro explained a problem that pygtk was running into. Their main loop function, ``gtk_main()``, blocks forever. If there are threads in the program, they cannot receive signals because Python catches the signal and calls ``Py_AddPendingCall()``, relying on the main thread to call ``Py_MakePendingCalls()``. Since with pygtk, the main thread is blocked calling a C function, it has no way other than polling to decide when ``Py_MakePendingCalls()`` needs to be called. Gustavo was hoping for some sort of API so that his blocking thread could get notified when ``Py_AddPendingCall()`` had been called.
There was a long discussion about the feasibility of this and other solutions to his problem. One of the main problems is that almost nothing can safely be done from a signal handler context, so some people felt like having Python invoke arbitrary third-party code was a bad idea. Gustavo was reasonably confident that he could write to a pipe within that context, which was all he needed to do to solve his problem, but Nick Maclaren explained in detail some of the problems, e.g. writing proper synchronization primitives that are signal-handler safe.
Jan Kanis suggested that threads in a pygtk program should occasionally check the signal handler flags and calls PyGTK's callback to wake up the main thread. But Gustavo explained that things like the GnomeVFS library have their own thread pools and know nothing about Python so can't make such a callback.
Adam Olsen suggested that Python could create a single non-blocking pipe for all signals. When a signal was handled, the signal number would be written to that pipe as a single byte. Third-party libraries, like pygtk, could poll the appropriate file descriptor, waking up and handing control back to Python when a signal was received. There were some disadvantages to this approach, e.g. if there is a large burst of signals, some of them would be lost, but folks seemed to think that these kinds of things would not cause many real-world problems. Gustavo and Adam then worked out the code in a little more detail.
The `Py_signal_pipe patch`_ was posted to SourceForge.
... _Py_signal_pipe patch: http://bugs.python.org/1564547
Contributing thread:
- `Signals, threads, blocking C functions <http://mail.python.org/pipermail/python-dev/2006-September/068569.html>`__
------------------------
API for str.rpartition()
------------------------
Raymond Hettinger pointed out that in cases where the separator was not found, ``str.rpartition()`` was putting the remainder of the string in the wrong spot, e.g. ``str.rpartition()`` worked like::
'axbxc'.rpartition('x') == ('axb', 'x', 'c')
'axb'.rpartition('x') == ('a', 'x', 'b')
'a'.rpartition('x') == ('a', '', '') # should be ('', '', 'a')
Thus code that used ``str.rpartition()`` in a loop or recursively would likely never terminate. Raymond checked in a fix for this, spawning an enormous discussion about how the three bits ``str.rpartition()`` returns should be named. There was widespread disagreement on which side was the "head" and which side was the "tail", and the only unambiguous one seemed to be "left, sep, right". Raymond and others were not as happy with this version because it was no longer suggestive of the use cases, but it looked like this might be the best compromise.
Contributing threads:
- `Problem withthe API for str.rpartition() <http://mail.python.org/pipermail/python-dev/2006-September/068565.html>`__
- `Fwd: Problem withthe API for str.rpartition() <http://mail.python.org/pipermail/python-dev/2006-September/068615.html>`__
---------------
Unicode Imports
---------------
Kristjan V. Jonsson submitted a `unicode import patch`_ that would allow unicode paths in sys.path and use the unicode file API on Windows. It got a definite "no" from the Python 2.5 release managers since it was already too late in the release process. Nonetheless there was a long discussion about whether or not it should be considered a bug or a feature. Martin v. Lowis explained that it was definitely a feature because it would break existing introspection tools expecting things like __file__ to be 8-bit strings (not unicode strings as they would be with the patch).
... _unicode import patch: http://bugs.python.org/1552880
Contributing thread:
- `Unicode Imports <http://mail.python.org/pipermail/python-dev/2006-September/068686.html>`__
-------------------------
Exception and __unicode__
-------------------------
Marcin 'Qrczak' Kowalczyk reported a `TypeError from unicode()`_ when applied to an Exception class. Brett Cannon explained the source of this: BaseException defined a ``__unicode__`` descriptor which was complaining when it was handed a class, not an instance. The easiest solution seemed to be the best for Python 2.5: simply rip out the ``__unicode__`` method entirely. M.-A. Lemburg suggested that for Python 2.6 this should be fixed by introducing a tp_unicode slot.
... _TypeError from unicode(): http://bugs.python.org/1551432
Contributing thread:
- `2.5 status <http://mail.python.org/pipermail/python-dev/2006-September/068607.html>`__
--------------------------
Slowdown in inspect module
--------------------------
Fernando Perez reported an enormous slowdown in Python 2.5's inspect module. Nick Coghlan figured out that this was a result of ``inspect.findsource()`` calling ``os.path.abspath()`` and ``os.path.normpath()`` repeatedly on the module's file name. Nick provided a `patch to speed things up`_ by caching the absolute, normalized file names.
... _patch to speed things up: http://bugs.python.org/1553314
Contributing thread:
- `inspect.py very slow under 2.5 <http://mail.python.org/pipermail/python-dev/2006-September/068656.html>`__
--------------------------------
Cross-platform float consistency
--------------------------------
Andreas Raab asked about trying to minimize some of the cross-platform differences in floating-point calcuations, by using something like fdlibm_. Tim Peters pointed him to a `previous thread on this issue`_ and suggested that best route was probably to package a Python wrapper for fdlibm_ and see how much interest there was.
... _fdlibm: http://www.netlib.org/fdlibm/
... _previous thread on this issue: http://mail.python.org/pipermail/python-list/2005-July/290164.html
Contributing thread:
- `Cross-platform math functions? <http://mail.python.org/pipermail/python-dev/2006-September/068599.html>`__
-----------------------------------
Refcounting and errors in functions
-----------------------------------
Mihai Ibanescu pointed out that refcount status for functions that can fail is generally poorly documented. Greg Ewing explained that refcounting behavior should be independent of whether the call succeeds or fails, but it was clear that this was not always the case. Mihai promised to file a low-severity bug so that this problem wouldn't be lost.
Contributing thread:
- `Py_BuildValue and decref <http://mail.python.org/pipermail/python-dev/2006-September/068708.html>`__
------------
Python 2.3.6
------------
Barry Warsaw offered to push out a Python 2.3.6 if folks were interested in getting some bugfixes out to the platforms which were still running Python 2.3. After an underwhelming response, he retracted the offer. (Stay tuned though - more on 2.3.6 in future summaries.)
Contributing threads:
- `Interest in a Python 2.3.6? <http://mail.python.org/pipermail/python-dev/2006-August/068520.html>`__
- `Interest in a Python 2.3.6? <http://mail.python.org/pipermail/python-dev/2006-September/068731.html>`__
- `Python 2.4.4 was: Interest in a Python 2.3.6? <http://mail.python.org/pipermail/python-dev/2006-September/068737.html>`__
-----------------------------------
Effbot Python library documentation
-----------------------------------
Johann C. Rocholl asked about the status of http://effbot.org/lib/, Fredrik Lundh's alternative format and rendering for the Python library documentation. Fredrik indicated that due to the pushback from some folks on python-dev, they've been working mainly "under the radar" on this. (At least until some inconsiderate soul put them in the summary...) ;-)
Contributing threads:
- `That library reference, yet again <http://mail.python.org/pipermail/python-dev/2006-August/068556.html>`__
- `That library reference, yet again <http://mail.python.org/pipermail/python-dev/2006-September/068561.html>`__
================
Deferred Threads
================
- `IronPython and AST branch <http://mail.python.org/pipermail/python-dev/2006-September/068778.html>`__
==================
Previous Summaries
==================
- `Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented <http://mail.python.org/pipermail/python-dev/2006-September/068564.html>`__
- `Error while building 2.5rc1 pythoncore_pgo on VC8 <http://mail.python.org/pipermail/python-dev/2006-September/068582.html>`__
- `gcc 4.2 exposes signed integer overflows <http://mail.python.org/pipermail/python-dev/2006-September/068602.html>`__
- `no remaining issues blocking 2.5 release <http://mail.python.org/pipermail/python-dev/2006-September/068606.html>`__
- `new security doc using object-capabilities <http://mail.python.org/pipermail/python-dev/2006-September/068673.html>`__
===============
Skipped Threads
===============
- `A test suite for unittest <http://mail.python.org/pipermail/python-dev/2006-September/068558.html>`__
- `Fwd: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc <http://mail.python.org/pipermail/python-dev/2006-September/068562.html>`__
- `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-September/068567.html>`__
- `Windows build slave down until Tuesday-ish <http://mail.python.org/pipermail/python-dev/2006-September/068573.html>`__
- `[Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined <http://mail.python.org/pipermail/python-dev/2006-September/068605.html>`__
- `Exception message for invalid with statement usage <http://mail.python.org/pipermail/python-dev/2006-September/068665.html>`__
- `buildbot breakage <http://mail.python.org/pipermail/python-dev/2006-September/068671.html>`__
- `Change in file() behavior in 2.5 <http://mail.python.org/pipermail/python-dev/2006-September/068678.html>`__
- `'with' bites Twisted <http://mail.python.org/pipermail/python-dev/2006-September/068681.html>`__
- `What windows tool chain do I need for python 2.5 extensions? <http://mail.python.org/pipermail/python-dev/2006-September/068709.html>`__
- `2.5c2 <http://mail.python.org/pipermail/python-dev/2006-September/068742.html>`__
- `_PyGILState_NoteThreadState should be static or not? <http://mail.python.org/pipermail/python-dev/2006-September/068743.html>`__
- `BRANCH FREEZE: release25-maint, 00:00UTC 12 September 2006 <http://mail.python.org/pipermail/python-dev/2006-September/068745.html>`__
- `datetime's strftime implementation: by design or bug <http://mail.python.org/pipermail/python-dev/2006-September/068747.html>`__
- `Subversion 1.4 <http://mail.python.org/pipermail/python-dev/2006-September/068761.html>`__
- `RELEASED Python 2.5 (release candidate 2) <http://mail.python.org/pipermail/python-dev/2006-September/068766.html>`__
- `Maybe we should have a C++ extension for testing... <http://mail.python.org/pipermail/python-dev/2006-September/068768.html>`__
- `.pyc file has different result for value "1.79769313486232e+308" than .py file <http://mail.python.org/pipermail/python-dev/2006-September/068769.html>`__
- `release is done, but release25-maint branch remains near-frozen <http://mail.python.org/pipermail/python-dev/2006-September/068773.html>`__
- `fun threading problem <http://mail.python.org/pipermail/python-dev/2006-September/068774.html>`__
- `Thank you all <http://mail.python.org/pipermail/python-dev/2006-September/068779.html>`__
========
Epilogue
========
This is a summary of traffic on the `python-dev mailing list`_ from
September 01, 2006 through September 15, 2006.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis. An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This python-dev summary is the 12th written by
Steve Bethard.
To contact me, please send email:
- Steve Bethard (steven.bethard at gmail.com)
Do *not* post to comp.lang.python if you wish to reach me.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python. It also tries to advance
the development and use of Python. If you find the python-dev Summary
helpful please consider making a donation. You can make a donation at
http://python.org/psf/donations.html . Every cent counts so even a
small donation with a credit card, check, or by PayPal helps.
--------------------
Commenting on Topics
--------------------
To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email (e-mail address removed) 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`_!
-------------------------
How to Read the Summaries
-------------------------
This summary is written using reStructuredText_. Any unfamiliar
punctuation is probably markup for reST_ (otherwise it is probably
regular expression syntax or a typo
; you can safely ignore it. We
do suggest learning reST, though; it's simple and is accepted for
`PEP markup`_ and can be turned into many different formats like HTML
and LaTeX.
... _python-dev: http://www.python.org/dev/
... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
... _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
... _PEP Markup: http://www.python.org/peps/pep-0012.html
... _reST:
... _reStructuredText: http://docutils.sf.net/rst.html
... _Python Software Foundation: http://python.org/psf/
... _archive: http://www.python.org/dev/summary/
... _RSS feed: http://www.python.org/dev/summary/channews.rdf
++++++++++++++++++++++++++++++++++++++++++++++++++++
... contents::
[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2006-09-01_2006-09-15]
=============
Announcements
=============
----------------------------
QOTF: Quote of the Fortnight
----------------------------
Through a cross-posting slip-up, Jean-Paul Calderone managed to provide us with some inspiring thoughts on mailing-list archives:
One could just as easily ask why no one bothers to read mailing list
archives to see if their question has been answered before.
No one will ever know, it is just one of the mysteries of the universe.
Contributing thread:
- `[Twisted-Python] Newbie question <http://mail.python.org/pipermail/python-dev/2006-September/068682.html>`__
-------------------------
Monthly Arlington sprints
-------------------------
Jeffrey Elkner has arranged for monthly Arlington Python sprints. See the `Arlington sprint wiki`_ for more details.
... _Arlington sprint wiki: http://wiki.python.org/moin/ArlingtonSprint
Contributing thread:
- `Arlington sprints to occur monthly <http://mail.python.org/pipermail/python-dev/2006-September/068688.html>`__
=========
Summaries
=========
-----------------------------------------
Signals, threads and blocking C functions
-----------------------------------------
Gustavo Carneiro explained a problem that pygtk was running into. Their main loop function, ``gtk_main()``, blocks forever. If there are threads in the program, they cannot receive signals because Python catches the signal and calls ``Py_AddPendingCall()``, relying on the main thread to call ``Py_MakePendingCalls()``. Since with pygtk, the main thread is blocked calling a C function, it has no way other than polling to decide when ``Py_MakePendingCalls()`` needs to be called. Gustavo was hoping for some sort of API so that his blocking thread could get notified when ``Py_AddPendingCall()`` had been called.
There was a long discussion about the feasibility of this and other solutions to his problem. One of the main problems is that almost nothing can safely be done from a signal handler context, so some people felt like having Python invoke arbitrary third-party code was a bad idea. Gustavo was reasonably confident that he could write to a pipe within that context, which was all he needed to do to solve his problem, but Nick Maclaren explained in detail some of the problems, e.g. writing proper synchronization primitives that are signal-handler safe.
Jan Kanis suggested that threads in a pygtk program should occasionally check the signal handler flags and calls PyGTK's callback to wake up the main thread. But Gustavo explained that things like the GnomeVFS library have their own thread pools and know nothing about Python so can't make such a callback.
Adam Olsen suggested that Python could create a single non-blocking pipe for all signals. When a signal was handled, the signal number would be written to that pipe as a single byte. Third-party libraries, like pygtk, could poll the appropriate file descriptor, waking up and handing control back to Python when a signal was received. There were some disadvantages to this approach, e.g. if there is a large burst of signals, some of them would be lost, but folks seemed to think that these kinds of things would not cause many real-world problems. Gustavo and Adam then worked out the code in a little more detail.
The `Py_signal_pipe patch`_ was posted to SourceForge.
... _Py_signal_pipe patch: http://bugs.python.org/1564547
Contributing thread:
- `Signals, threads, blocking C functions <http://mail.python.org/pipermail/python-dev/2006-September/068569.html>`__
------------------------
API for str.rpartition()
------------------------
Raymond Hettinger pointed out that in cases where the separator was not found, ``str.rpartition()`` was putting the remainder of the string in the wrong spot, e.g. ``str.rpartition()`` worked like::
'axbxc'.rpartition('x') == ('axb', 'x', 'c')
'axb'.rpartition('x') == ('a', 'x', 'b')
'a'.rpartition('x') == ('a', '', '') # should be ('', '', 'a')
Thus code that used ``str.rpartition()`` in a loop or recursively would likely never terminate. Raymond checked in a fix for this, spawning an enormous discussion about how the three bits ``str.rpartition()`` returns should be named. There was widespread disagreement on which side was the "head" and which side was the "tail", and the only unambiguous one seemed to be "left, sep, right". Raymond and others were not as happy with this version because it was no longer suggestive of the use cases, but it looked like this might be the best compromise.
Contributing threads:
- `Problem withthe API for str.rpartition() <http://mail.python.org/pipermail/python-dev/2006-September/068565.html>`__
- `Fwd: Problem withthe API for str.rpartition() <http://mail.python.org/pipermail/python-dev/2006-September/068615.html>`__
---------------
Unicode Imports
---------------
Kristjan V. Jonsson submitted a `unicode import patch`_ that would allow unicode paths in sys.path and use the unicode file API on Windows. It got a definite "no" from the Python 2.5 release managers since it was already too late in the release process. Nonetheless there was a long discussion about whether or not it should be considered a bug or a feature. Martin v. Lowis explained that it was definitely a feature because it would break existing introspection tools expecting things like __file__ to be 8-bit strings (not unicode strings as they would be with the patch).
... _unicode import patch: http://bugs.python.org/1552880
Contributing thread:
- `Unicode Imports <http://mail.python.org/pipermail/python-dev/2006-September/068686.html>`__
-------------------------
Exception and __unicode__
-------------------------
Marcin 'Qrczak' Kowalczyk reported a `TypeError from unicode()`_ when applied to an Exception class. Brett Cannon explained the source of this: BaseException defined a ``__unicode__`` descriptor which was complaining when it was handed a class, not an instance. The easiest solution seemed to be the best for Python 2.5: simply rip out the ``__unicode__`` method entirely. M.-A. Lemburg suggested that for Python 2.6 this should be fixed by introducing a tp_unicode slot.
... _TypeError from unicode(): http://bugs.python.org/1551432
Contributing thread:
- `2.5 status <http://mail.python.org/pipermail/python-dev/2006-September/068607.html>`__
--------------------------
Slowdown in inspect module
--------------------------
Fernando Perez reported an enormous slowdown in Python 2.5's inspect module. Nick Coghlan figured out that this was a result of ``inspect.findsource()`` calling ``os.path.abspath()`` and ``os.path.normpath()`` repeatedly on the module's file name. Nick provided a `patch to speed things up`_ by caching the absolute, normalized file names.
... _patch to speed things up: http://bugs.python.org/1553314
Contributing thread:
- `inspect.py very slow under 2.5 <http://mail.python.org/pipermail/python-dev/2006-September/068656.html>`__
--------------------------------
Cross-platform float consistency
--------------------------------
Andreas Raab asked about trying to minimize some of the cross-platform differences in floating-point calcuations, by using something like fdlibm_. Tim Peters pointed him to a `previous thread on this issue`_ and suggested that best route was probably to package a Python wrapper for fdlibm_ and see how much interest there was.
... _fdlibm: http://www.netlib.org/fdlibm/
... _previous thread on this issue: http://mail.python.org/pipermail/python-list/2005-July/290164.html
Contributing thread:
- `Cross-platform math functions? <http://mail.python.org/pipermail/python-dev/2006-September/068599.html>`__
-----------------------------------
Refcounting and errors in functions
-----------------------------------
Mihai Ibanescu pointed out that refcount status for functions that can fail is generally poorly documented. Greg Ewing explained that refcounting behavior should be independent of whether the call succeeds or fails, but it was clear that this was not always the case. Mihai promised to file a low-severity bug so that this problem wouldn't be lost.
Contributing thread:
- `Py_BuildValue and decref <http://mail.python.org/pipermail/python-dev/2006-September/068708.html>`__
------------
Python 2.3.6
------------
Barry Warsaw offered to push out a Python 2.3.6 if folks were interested in getting some bugfixes out to the platforms which were still running Python 2.3. After an underwhelming response, he retracted the offer. (Stay tuned though - more on 2.3.6 in future summaries.)
Contributing threads:
- `Interest in a Python 2.3.6? <http://mail.python.org/pipermail/python-dev/2006-August/068520.html>`__
- `Interest in a Python 2.3.6? <http://mail.python.org/pipermail/python-dev/2006-September/068731.html>`__
- `Python 2.4.4 was: Interest in a Python 2.3.6? <http://mail.python.org/pipermail/python-dev/2006-September/068737.html>`__
-----------------------------------
Effbot Python library documentation
-----------------------------------
Johann C. Rocholl asked about the status of http://effbot.org/lib/, Fredrik Lundh's alternative format and rendering for the Python library documentation. Fredrik indicated that due to the pushback from some folks on python-dev, they've been working mainly "under the radar" on this. (At least until some inconsiderate soul put them in the summary...) ;-)
Contributing threads:
- `That library reference, yet again <http://mail.python.org/pipermail/python-dev/2006-August/068556.html>`__
- `That library reference, yet again <http://mail.python.org/pipermail/python-dev/2006-September/068561.html>`__
================
Deferred Threads
================
- `IronPython and AST branch <http://mail.python.org/pipermail/python-dev/2006-September/068778.html>`__
==================
Previous Summaries
==================
- `Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented <http://mail.python.org/pipermail/python-dev/2006-September/068564.html>`__
- `Error while building 2.5rc1 pythoncore_pgo on VC8 <http://mail.python.org/pipermail/python-dev/2006-September/068582.html>`__
- `gcc 4.2 exposes signed integer overflows <http://mail.python.org/pipermail/python-dev/2006-September/068602.html>`__
- `no remaining issues blocking 2.5 release <http://mail.python.org/pipermail/python-dev/2006-September/068606.html>`__
- `new security doc using object-capabilities <http://mail.python.org/pipermail/python-dev/2006-September/068673.html>`__
===============
Skipped Threads
===============
- `A test suite for unittest <http://mail.python.org/pipermail/python-dev/2006-September/068558.html>`__
- `Fwd: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc <http://mail.python.org/pipermail/python-dev/2006-September/068562.html>`__
- `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-September/068567.html>`__
- `Windows build slave down until Tuesday-ish <http://mail.python.org/pipermail/python-dev/2006-September/068573.html>`__
- `[Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined <http://mail.python.org/pipermail/python-dev/2006-September/068605.html>`__
- `Exception message for invalid with statement usage <http://mail.python.org/pipermail/python-dev/2006-September/068665.html>`__
- `buildbot breakage <http://mail.python.org/pipermail/python-dev/2006-September/068671.html>`__
- `Change in file() behavior in 2.5 <http://mail.python.org/pipermail/python-dev/2006-September/068678.html>`__
- `'with' bites Twisted <http://mail.python.org/pipermail/python-dev/2006-September/068681.html>`__
- `What windows tool chain do I need for python 2.5 extensions? <http://mail.python.org/pipermail/python-dev/2006-September/068709.html>`__
- `2.5c2 <http://mail.python.org/pipermail/python-dev/2006-September/068742.html>`__
- `_PyGILState_NoteThreadState should be static or not? <http://mail.python.org/pipermail/python-dev/2006-September/068743.html>`__
- `BRANCH FREEZE: release25-maint, 00:00UTC 12 September 2006 <http://mail.python.org/pipermail/python-dev/2006-September/068745.html>`__
- `datetime's strftime implementation: by design or bug <http://mail.python.org/pipermail/python-dev/2006-September/068747.html>`__
- `Subversion 1.4 <http://mail.python.org/pipermail/python-dev/2006-September/068761.html>`__
- `RELEASED Python 2.5 (release candidate 2) <http://mail.python.org/pipermail/python-dev/2006-September/068766.html>`__
- `Maybe we should have a C++ extension for testing... <http://mail.python.org/pipermail/python-dev/2006-September/068768.html>`__
- `.pyc file has different result for value "1.79769313486232e+308" than .py file <http://mail.python.org/pipermail/python-dev/2006-September/068769.html>`__
- `release is done, but release25-maint branch remains near-frozen <http://mail.python.org/pipermail/python-dev/2006-September/068773.html>`__
- `fun threading problem <http://mail.python.org/pipermail/python-dev/2006-September/068774.html>`__
- `Thank you all <http://mail.python.org/pipermail/python-dev/2006-September/068779.html>`__
========
Epilogue
========
This is a summary of traffic on the `python-dev mailing list`_ from
September 01, 2006 through September 15, 2006.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis. An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This python-dev summary is the 12th written by
Steve Bethard.
To contact me, please send email:
- Steve Bethard (steven.bethard at gmail.com)
Do *not* post to comp.lang.python if you wish to reach me.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python. It also tries to advance
the development and use of Python. If you find the python-dev Summary
helpful please consider making a donation. You can make a donation at
http://python.org/psf/donations.html . Every cent counts so even a
small donation with a credit card, check, or by PayPal helps.
--------------------
Commenting on Topics
--------------------
To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email (e-mail address removed) 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`_!
-------------------------
How to Read the Summaries
-------------------------
This summary is written using reStructuredText_. Any unfamiliar
punctuation is probably markup for reST_ (otherwise it is probably
regular expression syntax or a typo
; you can safely ignore it. Wedo suggest learning reST, though; it's simple and is accepted for
`PEP markup`_ and can be turned into many different formats like HTML
and LaTeX.
... _python-dev: http://www.python.org/dev/
... _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
... _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
... _PEP Markup: http://www.python.org/peps/pep-0012.html
... _reST:
... _reStructuredText: http://docutils.sf.net/rst.html
... _Python Software Foundation: http://python.org/psf/
... _archive: http://www.python.org/dev/summary/
... _RSS feed: http://www.python.org/dev/summary/channews.rdf