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...@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/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
