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
_______________________________________________
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
