> On Jul 6, 2016, at 7:06 PM, Nathaniel Smith <n...@pobox.com> wrote:
>
> On Wed, Jul 6, 2016 at 1:12 PM, Yury Selivanov <yseliva...@gmail.com> wrote:
>> This is an interesting idea, but I wonder if instead of using ‘async with’
>> we can actually augment ‘async for’ to do the async finalization.
>>
>> We can add an __aiter_close__ special method which will return an awaitable.
>> In this case, ‘async for’ can always look for that method and call it at
>> the end of the iteration. Async generators will implement the method to
>> make sure that ‘finally’ is always executed (any number of awaits in
>> ‘finally’ is OK; ‘yield’ expressions cannot be used).
>
> I was wondering about that too. This is a fairly substantial change to
> how iterators work, though -- currently, it's totally legal and
> sometimes very useful to do things like
>
> it = open("...")
> # Discard header line (first non-commented line)
> for line in it:
> if not line.startswith("#"):
> break
> for body_line in it:
> …
Right. __aiter_close__ won’t work.
The problem is that the GC can’t execute async code, and we don’t have any
control over GC. What if we add a mechanism to control how async generators
(AG) are destructed. Let’s say we add new function to the sys module -
`sys.set_async_generator_finalizer(finalizer)`. We already have
sys.set_coroutine_wrapper(), so this isn’t something unprecedented.
With this new function, when an AG is about to be finalized, the interpreter
will resurrect it and call the `finalizer`. The finalizer function will be
installed by an event loop, and will execute ‘await AG.aclose()’ in the context
of that loop.
We can issue a ResourceWarning if an AG (not fully exhausted) is GCed and there
is no async finalizer.
Yury
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
