[Python-Dev] python-dev Summary for 2005-04-01 through 2005-04-15 [draft]

[Michael Hudson]

Tim Lesher <tlesher at 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