On 2016-10-21 11:19 AM, Gustavo Carneiro wrote:
Personally, I hadn't realised we had this problem in asyncio until now.
Does this problem happen in asyncio at all? Or does asyncio somehow work around it by making sure to always explicitly destroy the frames of all coroutine objects, as long as someone waits on each task?
No, I think asyncio code is free of the problem this proposal is trying to address. We might have some "problem" in 3.6 when people start using async generators more often. But I think it's important for us to teach people to manage the associated resources from the outside of the generator (i.e. don't put 'async with' or 'with' inside the generator's body; instead, wrap the code that uses the generator with 'async with' or 'with'). Yury
On 21 October 2016 at 16:08, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On 2016-10-21 6:29 AM, Steven D'Aprano wrote:
On Wed, Oct 19, 2016 at 05:52:34PM -0400, Yury Selivanov wrote:
[..]
With you proposal, to achieve the same (and make the code compatible
with new for-loop semantics), users will have to implement both __iterclose__ and __del__.
As I ask above, couldn't we just inherit a default __(a)iterclose__ from object that looks like this?
def __iterclose__(self): finalizer = getattr(type(self), '__del__', None) if finalizer: finalizer(self)
I know it looks a bit funny for non-iterables to have an iterclose method, but they'll never actually be called.
No, we can't call __del__ from __iterclose__. Otherwise we'd break even more code that this proposal already breaks:
for i in iter: ... iter.something() # <- this would be call after iter.__del__()
[..]
As for the amount of good, this proposal originally came from PyPy. I expect that CPython users won't appreciate it as much as PyPy users, and Jython/IronPython users when they eventually support Python 3.x.
AFAIK the proposal came "for" PyPy, not "from". And the issues Nathaniel tries to solve do also exist in CPython. It's only a question if changing 'for' statement and iteration protocol is worth the trouble.
Yury
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/