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

[Brett C.]

Tim Lesher wrote:
> 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.  We're trying a collaborative approach to the
> summaries: each fortnight, we'll be getting together in a virtual
> smoke-filled back room to divide up the interesting threads.  Then
> we'll stitch together the summaries in roughly the same form as you've
> seen in the past. We'll mark each editor's entries with his initials.
> 

Woohoo!  Once again, thanks for doing this guys.

> Thanks to Brett Cannon for sixty-one excellent python-dev summaries.
> Also, thanks for providing scripts to help get the new summaries off
> the ground! We're looking forward to the contributions you'll make to
> the Python core, now that the summaries aren't taking up all your
> time.
> 

Gee, no pressure.  =)

[SNIP]
> -------------------------------
> Security capabilities in Python
> -------------------------------
> 
> The issue of security came up again, and Ka-Ping Yee suggested that in
> Python's restricted execution mode secure proxies can be created by
> using lexical scoping.  He posted `some code`_ for revealing only
> certain "facets" of an object by using a function to declare a proxy
> class that used function local variables to build the proxy. Thus to

"... that used a function's local variables ..."

[SNIP]
> 
> ---------------------------------
> 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, 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."
> 
> Bob Ippolito wondered whether just calling PyEval_InitThreads directly
> in Py_Initialize might be a better idea.  No objections were raised,
> so long as the underlying OS locking mechanisms weren't overly
> expensive; some initial benchmarks indicated that this approach was
> viable, at least on Linux and OS X.
> 
> Contributing threads:
> 
> - `threading (GilState) question
> <http://mail.python.org/pipermail/python-dev/2005-April/052562.html>`__
> 
> .. _bug 1176893:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1176893&group_id=5470&atid=105470
> 

For any tracker item, the easiest way to do a URL is to use the python.org
shortcut: http://www.python.org/sf/##### .  So the above would be
http://www.python.org/sf/1176893 .

> .. _PEP 311: http://www.python.org/peps/pep-0311.html
> 
> [TDL]
> 
> ----------------------------------------
> Unicode byte order mark decoding
> ----------------------------------------
> 
> Evan Jones saw that the UTF-16 decoder discards the byte-order mark
> (BOM) from Unicode files, while the UTF-8 decoder doesn't. Although
> the BOM isn't really required in UTF-8 files, many Unicode-generating
> applications, especially on Microsoft platforms, add it.
> 
> Walter Dörwald created a patch_ to add a UTF-8-Sig codec that generates
> a BOM on writing and skips it on reading, but after a long discussion
> on the history of the Unicode, Microsoft's influence over its

"... of Unicode and Microsoft's influence ..."

[SNIP]
> ---------------
> Developers List
> ---------------
> 
> Raymond Hettinger has started a `project to track developers`_ and the
> (tracker and commit) privileges they have, and who gave them the privileges,
> and why (for example, was it for a one-shot project). Removing inactive
> developers should improve clarity, institutional memory, security, and makes
> everything tidier.  Raymond has begun contacting recently inactive
> developers to check whether they still require the privileges they have.
> 
> Contributing threads:
> 
>  - `Developer list update
> <http://mail.python.org/pipermail/python-dev/2005-April/052540.html>`__
> 
> .. _project to track developers:
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Misc/developers.txt
> 
> [TAM]
> 
> --------------------
> 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`_.
> 
> The consensus was that the correct behaviour is that packing a NaN or

"... behavious of packing a NaN ..."

[SNIP]


Well done guys!  Very impressed; succinct, clear, and a ton less errors then I
used to put into the first draft.  =)

When you are happy with the draft just email me the plaintext and I will get it
up on python.org for you.

-Brett