Paul Moore wrote:
> 2009/6/15 Terry Reedy :
>> 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 t
2009/6/15 Terry Reedy :
> 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
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 t
2009/6/15 Raymond Hettinger :
> 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
> that is m
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
i
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 tha
> 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
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 j
> 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
2009/6/14 Raymond Hettinger :
> 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 w
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, i
2009/6/13 Nick Coghlan :
> 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
> 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 Pending
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 almos
> 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
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
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 numbe
17 matches
Mail list logo
