Here's the first draft of the python-dev summary for the first half of<br>
May. Please send any corrections or suggestions to the summarizers (CC'ed).<br>
<br>
======================<br>
Summary Announcements<br>
======================<br>
<br>
----------------------------------------------<br>
PEP 340 Episode 2: Revenge of the With (Block)<br>
----------------------------------------------<br>
<br>
This fortnight's Python-Dev was dominated again by another nearly 400<br>
messages on the topic of anonymous block statements. The discussion<br>
was a little more focused than the last thanks mainly to Guido's<br>
introduction of `PEP 340`_. Discussion of this PEP resulted in a<br>
series of other PEPs, including<br>
<br>
* `PEP 342`_: Enhanced Iterators, which broke out into a separate<br>
PEP the parts of `PEP 340`_ that allowed code to pass values into<br>
iterators using ``continue EXPR`` and yield-expressions.<br>
<br>
* `PEP 343`_: Anonymous Block Redux, a dramatically simplified<br>
version of `PEP 340`_, which removed the looping nature of the<br>
anonymous blocks and the injection-of-exceptions semantics for<br>
generators.<br>
<br>
* `PEP 3XX`_: User Defined ("with") Statements, which proposed<br>
non-looping anonymous blocks accompanied by finalization semantics<br>
for iterators and generators in for loops.<br>
<br>
Various details of each of these proposals are discussed below in the<br>
sections:<br>
<br>
1. `Enhanced Iterators`_<br>
<br>
2. `Separate APIs for Iterators and Anonymous Blocks`_<br>
<br>
3. `Looping Anonymous Blocks`_<br>
<br>
4. `Loop Finalization`_<br>
<br>
At the time of this writing, it looked like the discussion was coming<br>
very close to a final agreement; `PEP 343`_ and `PEP 3XX`_ both agreed<br>
upon the same semantics for the block-statement, the keyword had been<br>
narrowed down to either ``do`` or ``with``, and Guido had agreed to<br>
add back in to `PEP 343`_ some form of exception-injection semantics<br>
for generators.<br>
<br>
<br>
.. _PEP 340: <a href="http://www.python.org/peps/pep-0340.html">http://www.python.org/peps/pep-0340.html</a><br>
<br>
.. _PEP 342: <a href="http://www.python.org/peps/pep-0342.html">http://www.python.org/peps/pep-0342.html</a><br>
<br>
.. _PEP 343: <a href="http://www.python.org/peps/pep-0343.html">http://www.python.org/peps/pep-0343.html</a><br>
<br>
.. _PEP 3XX: <a href="http://members.iinet.net.au/%7Encoghlan/public/pep-3XX.html">http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html</a><br>
<br>
[SJB]<br>
<br>
<br>
=========<br>
Summaries<br>
=========<br>
<br>
------------------<br>
Enhanced Iterators<br>
------------------<br>
<br>
`PEP 340`_ incorporated a variety of orthogonal features into a single<br>
proposal. To make the PEP somewhat less monolithic, the method for<br>
passing values into an iterator was broken off into `PEP 342`_. This<br>
method includes:<br>
<br>
* updating the iterator protocol to use .__next__() instead of .next()<br>
<br>
* introducing a new builtin next()<br>
<br>
* allowing continue-statements to pass values into iterators<br>
<br>
* allowing generators to receive values with a yield-expression<br>
<br>
Though these features had seemed mostly uncontroversial, Guido seemed<br>
inclined to wait for a little more motivation from the co-routiney<br>
people before accepting the proposal.<br>
<br>
Contributing threads:<br>
<br>
- `Breaking off Enhanced Iterators PEP from PEP 340 <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053463.html">http://mail.python.org/pipermail/python-dev/2005-May/053463.html</a>>`__<br>
<br>
[SJB]<br>
<br>
<br>
------------------------------------------------<br>
Separate APIs for Iterators and Anonymous Blocks<br>
------------------------------------------------<br>
<br>
`PEP 340`_ had originally proposed to treat the anonymous block<br>
protocol as an extension of the iterator protocol. Several problems<br>
with this approach were raised, including:<br>
<br>
* for-loops could accidentally be used with objects requiring blocks,<br>
meaning that resources would not get cleaned up properly<br>
<br>
* blocks could be used instead of for-loops, violating TOOWTDI<br>
<br>
As a result, both `PEP 343`_ and `PEP 3XX`_ propose decorators for<br>
generator functions that will wrap the generator object appropriately<br>
to match the anonymous block protocol. Generator objects without the<br>
proposed decorators would not be usable in anonymous block statements.<br>
<br>
Contributing threads:<br>
<br>
- `PEP 340 -- loose ends <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053206.html">http://mail.python.org/pipermail/python-dev/2005-May/053206.html</a>>`__<br>
- `PEP 340 -- concept clarification <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053280.html">http://mail.python.org/pipermail/python-dev/2005-May/053280.html</a>>`__<br>
<br>
[SJB]<br>
<br>
<br>
------------------------<br>
Looping Anonymous Blocks<br>
------------------------<br>
<br>
A few issues arose as a result of `PEP 340`_'s formulation of<br>
anonymous blocks as a variation on a loop.<br>
<br>
Because the anonymous blocks of `PEP 340`_ were defined in terms of<br>
while-loops, there was some discussion as to whether they should have<br>
an ``else`` clause like Python ``for`` and ``while`` loops do. There<br>
didn't seem to be one obvious interpretation of an ``else`` block<br>
though, so Guido rejected the ``else`` block proposal.<br>
<br>
The big issue with looping anonymous blocks, however, was in the<br>
handling of ``break`` and ``continue`` statements. Many use cases for<br>
anonymous blocks did not require loops. However, because `PEP 340`_<br>
anonymous blocks were implemented in terms of loops, ``break`` and<br>
``continue`` acted much like they would in a loop. This meant that in<br>
code like::<br>
<br>
for item in items:<br>
with lock:<br>
if handle(item):<br>
break<br>
<br>
the ``break`` statement would only break out of the anonymous block<br>
(the ``with`` statement) instead of breaking out of the for-loop. This<br>
pretty much shot-down `PEP 340`_; there were too many cases where an<br>
anonymous block didn't look like a loop, and having it behave like one<br>
would have been a major stumbling block in learning the construct.<br>
<br>
As a result, both `PEP 343`_ and `PEP 3XX`_ were proposed as<br>
non-looping versions of `PEP 340`_.<br>
<br>
<br>
Contributing threads:<br>
<br>
- `PEP 340: Else clause for block statements <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053190.html">http://mail.python.org/pipermail/python-dev/2005-May/053190.html</a>>`__<br>
- `PEP 340 -- loose ends <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053206.html">http://mail.python.org/pipermail/python-dev/2005-May/053206.html</a>>`__<br>
- `PEP 340 -- concept clarification <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053226.html">http://mail.python.org/pipermail/python-dev/2005-May/053226.html</a>>`__<br>
- `PEP 340: Breaking out. <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053223.html">http://mail.python.org/pipermail/python-dev/2005-May/053223.html</a>>`__<br>
- `PEP 340: Non-looping version (aka PEP 310 redux) <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053400.html">http://mail.python.org/pipermail/python-dev/2005-May/053400.html</a>>`__<br>
- `PEP 340 - Remaining issues <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053406.html">http://mail.python.org/pipermail/python-dev/2005-May/053406.html</a>>`__<br>
- `PEP 340: Deterministic Finalisation (new PEP draft, either a
competitor or update to PEP 340)
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053503.html">http://mail.python.org/pipermail/python-dev/2005-May/053503.html</a>>`__<br>
- `Merging PEP 310 and PEP 340-redux? <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053591.html">http://mail.python.org/pipermail/python-dev/2005-May/053591.html</a>>`__<br>
- `PEP 343 - Abstract Block Redux <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053731.html">http://mail.python.org/pipermail/python-dev/2005-May/053731.html</a>>`__<br>
<br>
[SJB]<br>
<br>
<br>
-----------------<br>
Loop Finalization<br>
-----------------<br>
<br>
Greg Ewing pointed out that a generator with a yield inside a<br>
block-statement would require additional work to guarantee its<br>
finalization. For example, if the generator::<br>
<br>
def all_lines(filenames):<br>
for name in filenames:<br>
with open(name) as f:<br>
for line in f:<br>
yield line <br>
<br>
were used in code like::<br>
<br>
for line in all_lines(filenames):<br>
if some_cond(line):<br>
break<br>
<br>
then unless the for-loop performed some sort of finalization on the<br>
all_lines generator, the last-opened file could remain open<br>
indefinitiely.<br>
<br>
As a result, `PEP 3XX`_ proposes that for-loops check for a<br>
__finish__() method on their iterators, and if one exists, call that<br>
method when the for-loop completes. Generators like all_lines above,<br>
that put a yield inside a block-statement, would then acquire a<br>
__finish__() method that would raise a TerminateIteration exception<br>
at the point of the last yield. The TerminateIteration exception would<br>
thus cause the block-statement to complete, guaranteeing that the<br>
generator was properly finalized.<br>
<br>
Contributing threads:<br>
<br>
- `PEP 340 - For loop cleanup, and feature separation
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053432.html">http://mail.python.org/pipermail/python-dev/2005-May/053432.html</a>>`__<br>
- `PEP 340: Deterministic Finalisation (new PEP draft, either a
competitor or update to PEP 340)
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053503.html">http://mail.python.org/pipermail/python-dev/2005-May/053503.html</a>>`__<br>
- `PEP 343 - Abstract Block Redux <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053731.html">http://mail.python.org/pipermail/python-dev/2005-May/053731.html</a>>`__<br>
<br>
[SJB]<br>
<br>
<br>
----------------------------<br>
Breaking out of Nested Loops<br>
----------------------------<br>
<br>
As a result of some of the issues of looping anonymous blocks, a few<br>
threads discussed options for breaking out of nested loops. These<br>
mainly worked by augmenting the ``break`` statement with another<br>
keyword (or keywords) that would indicate which loop to break out of.<br>
<br>
One proposal suggested that ``break`` be followed with ``for`` or<br>
``while`` to indicate which loop to break out of. But ``break for``<br>
would only really be useful in a while-loop nested within a for-loop,<br>
and ``break while`` would only really be useful in a for-loop nested<br>
within a while-loop. That is, because loops could only be named by<br>
type, the proposal was only useful when loops of different types were<br>
mixed. This suggestion was thus discarded as not being general enough.<br>
<br>
A few other suggestions were briefly discussed: adding labels to<br>
loops, using an integer to indicate which "stack level" to break at,<br>
and pushing breaks onto a "break buffer", but Guido killed the<br>
discussion, saying, `"Stop all discussion of breaking out of multiple<br>
loops. It ain't gonna happen before my retirement."<br>
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053592.html">http://mail.python.org/pipermail/python-dev/2005-May/053592.html</a>>`__<br>
<br>
Contributing threads:<br>
<br>
- `PEP 340: Breaking out. <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053223.html">http://mail.python.org/pipermail/python-dev/2005-May/053223.html</a>>`__<br>
- `PEP 340: Deterministic Finalisation (new PEP draft, either a
competitor or update to PEP 340)
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053503.html">http://mail.python.org/pipermail/python-dev/2005-May/053503.html</a>>`__<br>
<br>
[SJB]<br>
<br>
<br>
------------------------<br>
The future of exceptions<br>
------------------------<br>
<br>
Ka-Ping Yee suggested that instead of passing (type, value, traceback)<br>
tuples in exceptions it would be better to put the traceback in<br>
value.traceback. Guido had also suggested this (in the `PEP 340`_ murk) but<br>
pointed out that this would not work as long as string exceptions exist<br>
(as there is nowhere to put the traceback).<br>
<br>
Guido noted that there are no concrete plans as to when string exceptions<br>
will be deprecated and removed (other than in 3.0 at the latest); he<br>
indicated that it could be sooner, if someone wrote a PEP with a timeline<br>
(e.g. deprecated in 2.5, gone in 2.6).<br>
<br>
Brett C. volunteered to write a PEP targetted at Python 3000 covering<br>
exception changes (base inheritance, standard attributes (e.g. .traceback),<br>
reworking the built-in exception inheritance hierarchy, and the future of<br>
bare except statements). <br>
<br>
Contributing threads:<br>
<br>
- `Tidier Exceptions <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053671.html">http://mail.python.org/pipermail/python-dev/2005-May/053671.html</a>>`__<br>
<br>
.. _PEP 340: <a href="http://www.python.org/peps/pep-0340.html">http://www.python.org/peps/pep-0340.html</a><br>
<br>
[TAM]<br>
<br>
<br>
-----------------------------------<br>
Unifying try/except and try/finally<br>
-----------------------------------<br>
<br>
Reinhold Birkenfeld submitted a Pre-PEP to allow both except and finally<br>
clauses in try blocks. For example, a construction like::<br>
<br>
try:<br>
<suite 1><br>
except Ex1:<br>
<suite 2><br>
<more except: clauses><br>
else:<br>
<suite 3><br>
finally:<br>
<suite 4><br>
<br>
would be exactly the same as the legacy::<br>
<br>
try:<br>
try:<br>
<suite 1><br>
except Ex1:<br>
<suite 2><br>
<more except: clauses><br>
else:<br>
<suite 3><br>
finally:<br>
<suite 4><br>
<br>
Guido liked this idea (so much that he wanted to accept it immediately),<br>
and recommended that it was checked in as a PEP. However, Tim Peters<br>
pointed out that this functionality was removed from Python (by Guido) way<br>
back in 0.9.6, seemingly because there was confusion about exactly when<br>
the finally clause would be called (explicit is better than implicit!).<br>
Guido clarified that control would only pass forward, and indicated that<br>
he felt that since this is now available in Java (and C#) fewer people<br>
would be confused. The main concern about this change was that, while the<br>
cost was low, it seemed to add very little value.<br>
<br>
Contributing threads:<br>
<br>
- `Pre-PEP: Unifying try-except and try-finally <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053290.html">http://mail.python.org/pipermail/python-dev/2005-May/053290.html</a>>`__<br>
<br>
[TAM]<br>
<br>
<br>
-----------------<br>
Decorator Library<br>
-----------------<br>
<br>
Michele Simionato asked whether a module for commonly used decorators, or<br>
utilities to create decorators, was planned. Raymond Hettinger indicated<br>
that while this was likely in the long term, he felt that it was better if<br>
these first evolved via wikis, recipes, or mailing lists, so that a module<br>
would only be added once best practices and proven winners had emerged.<br>
In the meantime, there is both a `Decorator Library wiki page`_ and<br>
you can try out `Michele's library`_ [zip].<br>
<br>
To assist with decorator creation, Michele would like a facility to copy a<br>
function. Phillip J. Eby noted that the informally-discussed proposal is<br>
to add a mutable __signature__ to functions to assist with signature<br>
preserving decorators. Raymond suggested a patch adding a __copy__ method<br>
to functions or a patch for the copy module, and Michele indicated that he<br>
would also like to subclass FunctionType with an user-defined __copy__<br>
method.<br>
<br>
Contributing threads:<br>
<br>
- `my first post: asking about a "decorator" module <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053316.html">http://mail.python.org/pipermail/python-dev/2005-May/053316.html</a>>`__<br>
- `The decorator module <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053446.html">http://mail.python.org/pipermail/python-dev/2005-May/053446.html</a>>`__<br>
<br>
.. _Decorator Library wiki page: <a href="http://www.python.org/moin/PythonDecoratorLibrary">http://www.python.org/moin/PythonDecoratorLibrary</a> <br>
.. _Michele's library: <a href="http://www.phyast.pitt.edu/%7Emicheles/python/decorator.zip">http://www.phyast.pitt.edu/~micheles/python/decorator.zip</a> <br>
<br>
[TAM]<br>
<br>
---------------------<br>
Hooking Py_FatalError<br>
---------------------<br>
<br>
Errors that invoke Py_FatalError generally signify that the internal state<br>
of Python is in such a poor state that continuing (including raising an<br>
exception) is impossible or unwise; as a result, Py_FatalError outputs the<br>
error to stderr and calls abort(). m.u.k. would like to have a callback to<br>
hook Py_FatalError to avoid this call to abort(). The general consensus<br>
was that effort would be better directed to fixing the causes of fatal<br>
errors than hooking Py_FatalError. m.u.k.'s use case was for generating<br>
additional logging information; a `callback system patch`_ (revised by<br>
James William Pye) is available for those interested.<br>
<br>
Contributing threads:<br>
<br>
- `Need to hook Py_FatalError <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053218.html">http://mail.python.org/pipermail/python-dev/2005-May/053218.html</a>>`__<br>
<br>
.. _callback system patch: <a href="http://python.org/sf/1195571">http://python.org/sf/1195571</a><br>
<br>
-------------------<br>
Chaining Exceptions<br>
-------------------<br>
<br>
Ka-Ping Yee suggested adding information to exceptions when they are raised<br>
in the handler for another exception. For example::<br>
<br>
def a():<br>
try:<br>
raise AError<br>
except:<br>
raise BError<br>
<br>
raises an exception which is an instance of BError. This instance could<br>
have an attribute which is instance of AError, containing information about<br>
the original exception. Use cases include catching a low-level exception<br>
(e.g. socket.error) and turning it into a high-level exception (e.g.<br>
an HTTPRequestFailed exception) and handling problems in exception handling<br>
code. Guido liked the idea, and discussion fleshed out a tighter<br>
definition; however it was unclear whether adding this now was feasible -<br>
this would perhaps be best added in Python 3000.<br>
<br>
Contributing threads:<br>
<br>
- `Chained Exceptions <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053672.html">http://mail.python.org/pipermail/python-dev/2005-May/053672.html</a>>`__<br>
<br>
[TAM]<br>
<br>
------------------<br>
Py_UNICODE madness<br>
------------------<br>
<br>
Nicholas Bastin noted an apparent bug in the documentation for<br>
Py_UNICODE, which states that Py_UNICODE is 16-bit value implemented<br>
as an alias for wchar_t when that type is available, and for unsigned<br>
short otherwise However, on recent Redhat releases, PY_UNICODE_SIZE<br>
turns out to be 4. Guido and Marc-Andres Lemburg both agreed that the<br>
documentation is incorrect, so Nicholas set out to fix the<br>
documentation by removing the 16-bit reference and adding a caveat for<br>
extension developers not to make assumptions about the size of Py_UNICODE.<br>
<br>
It wasn't *quite* that simple. A long discussion ensued over why<br>
Python sometimes needs to default to UCS-4 Unicode (to avoid<br>
breaking an existing UCS-4 Tkinter), whether to expose the size of<br>
Py_UNICODE to extension developers (they won't take 'no' for an<br>
answer), and whether Python should provide better support for high<br>
surrogate pairs (it should). The matter remained open.<br>
<br>
Contributing threads:<br>
<br>
- `Py_UNICODE madness <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053264.html">http://mail.python.org/pipermail/python-dev/2005-May/053264.html</a>>`__<br>
- `New Py_UNICODE doc <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053311.html">http://mail.python.org/pipermail/python-dev/2005-May/053311.html</a>>`__<br>
- `New Py_UNICODE doc (Another Attempt) <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053480.html">http://mail.python.org/pipermail/python-dev/2005-May/053480.html</a>>`__<br>
<br>
<br>
[TDL]<br>
<br>
------------------------------<br>
Python's Unicode width default <br>
------------------------------<br>
<br>
Marc-Andre Lemburg objected to Python's build process automatically<br>
changing its default Unicode size from UCS2 to UCS4 at build time when<br>
a UCS4 version of Tcl is found. Martin Löwis argued that having<br>
Tkinter always work out of the box was more important than having a<br>
hard-and-fast Unicode default configuration; Marc dissented.<br>
<br>
Shane Hathaway opined that it could be a runtime rather than a<br>
compile-time decision, and Bob Ippolito mentioned NSString from<br>
OpenDarwin's libFoundation and CFString from Apple's CoreFoundation<br>
libraries for implementation ideas.<br>
<br>
Contributing threads:<br>
<br>
- `Python's Unicode width default (New Py_UNICODE doc)
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053574.html">http://mail.python.org/pipermail/python-dev/2005-May/053574.html</a>>`__<br>
<br>
[TDL]<br>
<br>
===============<br>
Skipped Threads<br>
===============<br>
<br>
- `Keyword for block statements <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053189.html">http://mail.python.org/pipermail/python-dev/2005-May/053189.html</a>>`__<br>
- `PEP 340 - possible new name for block-statement <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053195.html">http://mail.python.org/pipermail/python-dev/2005-May/053195.html</a>>`__<br>
- `Generating nested data structures with blocks <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053204.html">http://mail.python.org/pipermail/python-dev/2005-May/053204.html</a>>`__<br>
- `PEP 340 -- Clayton's keyword? <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053377.html">http://mail.python.org/pipermail/python-dev/2005-May/053377.html</a>>`__<br>
- `PEP 340: Only for try/finally? <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053258.html">http://mail.python.org/pipermail/python-dev/2005-May/053258.html</a>>`__<br>
- `2 words keyword for block <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053251.html">http://mail.python.org/pipermail/python-dev/2005-May/053251.html</a>>`__<br>
- `anonymous blocks <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053297.html">http://mail.python.org/pipermail/python-dev/2005-May/053297.html</a>>`__<br>
- `"begin" as keyword for pep 340 <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053315.html">http://mail.python.org/pipermail/python-dev/2005-May/053315.html</a>>`__<br>
- `PEP 340: propose to get rid of 'as' keyword <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053320.html">http://mail.python.org/pipermail/python-dev/2005-May/053320.html</a>>`__<br>
- `PEP 340 keyword: after <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053396.html">http://mail.python.org/pipermail/python-dev/2005-May/053396.html</a>>`__<br>
- `PEP 340 keyword: Extended while syntax <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053409.html">http://mail.python.org/pipermail/python-dev/2005-May/053409.html</a>>`__<br>
- `PEP 340 - Remaining issues - keyword <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053428.html">http://mail.python.org/pipermail/python-dev/2005-May/053428.html</a>>`__<br>
- `PEP 340: Examples as class's. <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053423.html">http://mail.python.org/pipermail/python-dev/2005-May/053423.html</a>>`__<br>
- `Proposed alternative to __next__ and __exit__ <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053514.html">http://mail.python.org/pipermail/python-dev/2005-May/053514.html</a>>`__<br>
- `"with" use case: exception chaining <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053665.html">http://mail.python.org/pipermail/python-dev/2005-May/053665.html</a>>`__<br>
- `PEP 343: Resource Composition and Idempotent __exit__
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053767.html">http://mail.python.org/pipermail/python-dev/2005-May/053767.html</a>>`__<br>
- `[Python-checkins] python/nondist/peps pep-0343.txt, 1.8, 1.9
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053766.html">http://mail.python.org/pipermail/python-dev/2005-May/053766.html</a>>`__<br>
- `the current behavior of try: ... finally: <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053692.html">http://mail.python.org/pipermail/python-dev/2005-May/053692.html</a>>`__<br>
- `a patch to inspect and a non-feature request <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053653.html">http://mail.python.org/pipermail/python-dev/2005-May/053653.html</a>>`__<br>
- `Python 2.4 set objects and cyclic garbage <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053630.html">http://mail.python.org/pipermail/python-dev/2005-May/053630.html</a>>`__<br>
- `CHANGE BayPIGgies: May *THIRD* Thurs <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053628.html">http://mail.python.org/pipermail/python-dev/2005-May/053628.html</a>>`__<br>
- `Python continually calling sigprocmask() on FreeBSD 5
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053615.html">http://mail.python.org/pipermail/python-dev/2005-May/053615.html</a>>`__<br>
- `Weekly Python Patch/Bug Summary <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053213.html">http://mail.python.org/pipermail/python-dev/2005-May/053213.html</a>>`__<br>
- `problems with memory management <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053408.html">http://mail.python.org/pipermail/python-dev/2005-May/053408.html</a>>`__<br>
- `Adding DBL_MANTISSA and such to Python <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053372.html">http://mail.python.org/pipermail/python-dev/2005-May/053372.html</a>>`__<br>
- `python-dev Summary for 2005-04-16 through 2005-04-30 [draft]
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053383.html">http://mail.python.org/pipermail/python-dev/2005-May/053383.html</a>>`__<br>
- `Python Language track at Europython, still possibilities to submit
talks
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053303.html">http://mail.python.org/pipermail/python-dev/2005-May/053303.html</a>>`__<br>
- `(no subject) <<a href="http://mail.python.org/pipermail/python-dev/2005-May/053196.html">http://mail.python.org/pipermail/python-dev/2005-May/053196.html</a>>`__<br>
- `Kernel panic writing to /dev/dsp with cmpci driver
<<a href="http://mail.python.org/pipermail/python-dev/2005-May/053627.html">http://mail.python.org/pipermail/python-dev/2005-May/053627.html</a>>`__<br>
<br><br>-- <br>Tim Lesher <<a href="mailto:tlesher@gmail.com">tlesher@gmail.com</a>>