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.
I think the problem was a little bit more subtle: nested() gets passed
managers, so their __init__()s should all have run when the first
context
Hagen Fürstenau wrote:
I actually almost asked for that to be changed to a
PendingDeprecationWarning when it was first added - Benjamin, do you
mind if I downgrade this warning to a pending one post rc2?
I'm not sure what that would buy us. For the use case I mentioned it
would be just as
Unlike a full DeprecationWarning, a PendingDeprecationWarning is ignored
by default. You have to switch them on explicitly via code or a command
line switch in order to see them.
Sorry, I should have made myself more familiar with the warnings
mechanism before writing. In that case I'm fine
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
I don't consider changing a DeprecationWarning to a
PendingDeprecationWarning resurrecting its target.
Seems like resurrection to me. Pending warnings are hidden
by default, so someone has to go look for it (and no one does this).
The problem with the nested() construct is not so much that
it
2009/6/15 Raymond Hettinger pyt...@rcn.com:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
Right now, the current example just shows the hazardous pattern
Raymond Hettinger wrote:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
It could even suggest that it only be used for this, since it may
disappear, and
2009/6/15 Terry Reedy tjre...@udel.edu:
Raymond Hettinger wrote:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
It could even suggest that it only be
Paul Moore wrote:
2009/6/15 Terry Reedy tjre...@udel.edu:
Raymond Hettinger wrote:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
It could even suggest
I actually almost asked for that to be changed to a
PendingDeprecationWarning when it was first added - Benjamin, do you
mind if I downgrade this warning to a pending one post rc2?
I'm not sure what that would buy us. For the use case I mentioned it
would be just as annoying to get a
2009/6/13 Nick Coghlan ncogh...@gmail.com:
Hagen Fürstenau wrote:
I guess this is much too late for 3.1, but could we then at least
un-deprecate contextlib.nested for now? As it is, you get a
DeprecationWarning for something like
with contextlib.nested(*my_managers):
without any good way
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,
2009/6/14 Raymond Hettinger pyt...@rcn.com:
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
The semantic change actually needed to make nested() more equivalent to
the multi-with statement is for it to accept zero-argument callables
that create context managers as arguments rather than pre-created
context managers.
It seems to me that both passing callables which return managers and
Hagen Fürstenau wrote:
I guess this is much too late for 3.1, but could we then at least
un-deprecate contextlib.nested for now? As it is, you get a
DeprecationWarning for something like
with contextlib.nested(*my_managers):
without any good way to get rid of it.
I actually almost asked
contextlib.nested has recently been deprecated on grounds of being
unnecessary now that the with statement accepts multiple context
managers. However, as has been mentioned before
(http://mail.python.org/pipermail/python-dev/2009-May/089359.html), that
doesn't cover the case of a variable
Hagen Fürstenau wrote:
I'm proposing to add an iterator version of nested to contextlib
(possibly called inested), which takes an iterable of context managers
instead of a variable number of parameters. The implementation could be
taken over from the present nested, only changing def
17 matches
Mail list logo
