Ask Solem a...@celeryproject.org added the comment:
How would you replace the following functionality
with the multiple with statement syntax:
x = (A(), B(), C())
with nested(*x) as context:
It seems to me that nested() is still useful for this particular
use case.
Nick Coghlan ncogh...@gmail.com added the comment:
Indeed it is, although we think actually doing that is a bad idea (as discussed
earlier on this tracker item).
See the 3.1 docs for the recommended workaround for the removal (basically grab
a copy of the 3.1 code and drop it into your own
Nick Coghlan ncogh...@gmail.com added the comment:
Docstring updated in r73518 (2.7) and r73520 (3.1)
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6288
Nick Coghlan ncogh...@gmail.com added the comment:
In light of Raymond's comments (which make sense to me), I'm just
updating the documentation and leaving the full deprecation warning in
place.
The new docs are deliberately explicit about *why* trying to use the
current form of nested is
Nick Coghlan ncogh...@gmail.com added the comment:
And done for 3.1 in r73466
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6288
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Nice job on the new wording in the docs.
Do you think the docstring should also be updated?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6288
Nick Coghlan ncogh...@gmail.com added the comment:
Good point - I forgot about the docstring.
Yes, I think that should be changed to use the new wording up to the new
example (similar to the way the old docstring stopped at the example).
Reopening until that is done (although reducing from
Hagen Fürstenau hfuerste...@gmx.net added the comment:
Does that mean that nested() can be removed or changed incompatibly in
3.2 at the same time that an alternative way for handling the remaining
use case is introduced?
This would seem to violate the promise in PEP 5, that users will have
at
Nick Coghlan ncogh...@gmail.com added the comment:
That's a good point actually - with 3.1's in-between status and the
lack of deprecation in 2.6, nested() is going to have to stick around
for 2.7/3.2 anyway.
So PendingDeprecation now with full deprecation in 2.7/3.2 when we will
hopefully have
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
There is *no* reason to downgrade the warning. We can leave it as
deprecated in 3.1 and remove it in 3.3 if we want.
A PendingDeprecationWarning is just a plain bad idea, it doesn't
actually warn the users. We introduced
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
To be clear, I'm strongly -1 on switching to a PendingDeprecationWarning.
That is not what it is for. There is nothing in the PEP 5 language that
requires it (a PDW isn't even mentioned, the pep is mainly targeted at
deep
New submission from Nick Coghlan ncogh...@gmail.com:
Just a placeholder to remind me to implement the suggestion from
python-dev of updating the contextlib.nested docs to show:
1. The one remaining valid use case (variable number of context managers)
2. The warnings module incantation needed to
12 matches
Mail list logo
