[Python-Dev] Iterator version of contextlib.nested

Nick Coghlan ncoghlan at gmail.com
Mon Jun 15 13:13:03 CEST 2009


Raymond Hettinger wrote:
> I suggest a PEP for 2.7 and 3.2 for building-out the
> with-statement to support tuples of context managers
> (perhaps modeled after the syntax for except-statements
> which allows either individual exceptions or tuples of
> exceptions).  The reason I suggest a PEP is that use
> cases need to be fully thought out and the failing
> constructor problem needs to be dealt with. 
> IMO, this represents doing-it-the-right-way instead of preserving a
> construct that is known to be problematic.
> Leaving it in will enshrine it.  Better to  just provide our new
> syntax that correctly handles the common case and then
> wait to carefully think through how to add support for passed-in
> nested cm's if in-fact those turn-out to have reasonable
> use cases.

I agree that the current incarnation of contextlib.nested needs to go -
it isn't really salvagable in its current form.

However, I don't think we should generate a warning for it by default
until we provide a new mechanism for handling a variable number of
context managers - PendingDeprecationWarning seems a much better fit.

A 2.7/3.2 PEP can then address the two main issues with the current
approach:

1. The __init__ calls for the inner context managers occur outside the
scope of the outer context managers. Some form of lazy evaluation would
be needed to deal with that.

2. If an inner __enter__ call raises an exception that is suppressed by
an outer __exit__ call then the body of with statement should be skipped
rather than raising RuntimeError. This means either new syntax with
semantics along the lines of the previously rejected PEP 377 or else a
custom exception and a second context manager that suppresses it.

Personally, I don't think new syntax for the PEP 377 semantics is
warranted for the same reason that PEP 377 itself was rejected - it
complicates the statement definition significantly for a really obscure
corner case. Better to come up with a new and improved version of nested
that eliminates (or better handles) the quirks and leave the statement
definition alone.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


More information about the Python-Dev mailing list