Tim Lesher <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
