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

Monthly Arlington sprints

Jeffrey Elkner has arranged for monthly Arlington Python sprints. See the Arlington sprint wiki for more details.

Contributing thread:

• Arlington sprints to occur monthly

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.

Contributing thread:

• Signals, threads, blocking C functions

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()
• Fwd: Problem withthe API for str.rpartition()

Unicode Imports

Kristján V. Jónsson 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. Löwis 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).

Contributing thread:

• Unicode Imports

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.

Contributing thread:

• 2.5 status

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.

Contributing thread:

• inspect.py very slow under 2.5

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.

Contributing thread:

• Cross-platform math functions?

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

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?
• Interest in a Python 2.3.6?
• Python 2.4.4 was: Interest in a Python 2.3.6?

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
• That library reference, yet again

Commenting on Topics

To comment on anything mentioned here, just post to comp.lang.python (or email python-list@python.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!

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.