FWIW, I think resurrecting contextlib.nested() is a bad idea.
Part of the justification for the new with-statement syntax was
that nested() doesn't have a way to finalize the constructors
if one of them fails. It is a pitfall for the unwary. And now
that we have the new with-statement syntax, it mostly just
represents a second-way-to-do-it (a second way that has
has the stated pitfall).
The new statement was not designed to support passing in
tuples of context-managers. This issue was raised while
the new with-statement was being designed and it was
intentionally left-out (in part, because the use cases were
questionable and in-part because there were other ways
to do it such as adding __enter__ and __exit__ to tuple).
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.
Raymond
_______________________________________________
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
