Home Original page

[Python-ideas] Deterministic iterator cleanup

Yury Selivanov yselivanov.ml at gmail.com
Fri Oct 21 12:56:16 EDT 2016 
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 at 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 at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
More information about the Python-ideas mailing list