Tim Lesher <tlesher@gmail.com> writes:
Here's the first draft of the python-dev summary for the first half of April. Please send any corrections or suggestions to the summarizers.
====================== Summary Announcements ======================
--------------------------- New python-dev summary team ---------------------------
This summary marks the first by the team of Steve Bethard, Tim Lesher, and Tony Meyer.
Nice work! An update:
--------------------------------- Improving GilState API Robustness ---------------------------------
Michael Hudson noted that his changes to thread handling in the readline module appeared to trigger `bug 1176893`_ ("Readline segfault"). However, he believed the problem lay in the GilState API, rather than in his changes: PyGilState_Release crashes if PyEval_InitThreads wasn't called, even if the code you're writing doesn't use multiple threads.
He proposed several solutions, none of which met with resounding approbation,
Nevertheless, I've checked one of them in :) After reading a fair bit of code, and docs, I went for option 2) in the linked mail.
and Tim Peters noted that `PEP 311`_, Simplified Global Interpreter Lock Acquisition for Extensions, "specifically disowns responsibility for worrying about whether Py_Initialize and PyEval_InitThreads have been called."
I think this reading is a bit of a stretch of the wording of the PEP. It also contradicts the documentation ("regardless of the current state of Python"). Finally, the current behaviour has a strong whiff of being accidental.
-------------------- Marshalling Infinity --------------------
Scott David Daniels kicked off a very long thread by asking what (un)marshal should do with floating point NaNs. The current behaviour (as with any NaN, infinity, or signed zero) is undefined: a platform-dependant accident, because Python is written to C89, which has no such concepts. Tim Peters pointed out all code for (de)serialing C doubles should go through _PyFloat_Pack8()/_PyFloat_Unpack8(), and that the current implementation suggests that the routines could simply copy bytes on platforms that use the standard IEEE-754 single and double formats natively. Michael Hudson obliged by creating a `patch to implement this`_.
I hope to check this in soon. Note that the patch is in two pieces, one to marshal floats in binary format and one ...
The consensus was that the correct behaviour is that packing a NaN or infinity shouldn't cause an exception. When unpacking, an IEEE-754 platform shouldn't cause an exception, but a non-754 platform should, since there's no sensible value that it can be unpacked to, and errors should never pass silently.
... to do this bit.
--------------------------------- Location of the sign bit in longs ---------------------------------
Michael Hudson asked about the possibility of longs storing the sign bit somewhere other than the current location, suggesting the top bit of ob_digit[0]. Tim Peters suggested that it would be better to give struct _longobject a distinct sign member. This simplifies code, costs no extra bytes for some longs, and 8 extra bytes for others, and shouldn't hurt binary compatibility.
Michael coughed up a `longobject patch`_, which seems likely to be checked in.
I'm actually in less of a rush to get this one in :) (Hmm, had a busy couple of weeks, didn't I? :)
Contributing threads:
- `marshal / unmarshal <http://mail.python.org/pipermail/python-dev/2005-April/052593.html>`__
? Cheers, mwh -- <wzZzy> we should write an os <itamar> YES * itamar starts a sourceforge project -- from Twisted.Quotes