On 24.08.2016 18:35, Guido van Rossum wrote:
> On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov
> <yselivanov.ml at gmail.com <mailto:yselivanov.ml at gmail.com>> wrote:
>
> On 2016-08-23 10:38 PM, Rajiv Kumar wrote:
>
> I was playing with your implementation to gain a better
> understanding of the operation of asend() and friends. Since I
> was explicitly trying to "manually" advance the generators, I
> wasn't using asyncio or other event loop. This meant that the
> first thing I ran into with my toy code was the RuntimeError
> ("cannot iterate async generator without finalizer set").
>
> As you have argued elsewhere, in practice the finalizer is
> likely to be set by the event loop. Since the authors of event
> loops are likely to know that they should set the finalizer,
> would it perhaps be acceptable to merely issue a warning
> instead of an error if the finalizer is not set? That way
> there isn't an extra hoop to jump through for simple examples.
>
> In my case, I just called
> sys.set_asyncgen_finalizer(lambda g: 1)
> to get around the error and continue playing :) (I realize
> that's a bad thing to do but it didn't matter for the toy cases)
>
>
> Yeah, maybe warning would be sufficient. I just find it's highly
> unlikely that a lot of people would use async generators without a
> loop/coroutine runner, as it's a very tedious process.
>
>
> Heh, I had the same reaction as Rajiv. I think the tediousness is
> actually a good argument that there's no reason to forbid this. I
> don't even think a warning is needed. People who don't use a coroutine
> runner are probably just playing around (maybe even in the REPL) and
> they shouldn't get advice unasked.
I also was irritated as Yury said there were absolutely no changes after
python-ideas. He said he might consider a clearer warning for those
examples at the beginning of the PEP to make them work for the reader.
>
> Would it be possible to print a warning only when an async generator
> is being finalized and doesn't run straight to the end without
> suspending or yielding? For regular generators we have a similar
> exception (although I don't recall whether we actually warn) -- if you
> call close() and it tries to yield another value it is just GC'ed
> without giving the frame more control. For an async generator there
> are two cases: either it tries to yield another value (the first time
> this happens you can throw an error back into it) or it tries to await
> -- in that case you can also throw an error back into it, and if the
> error comes out unhandled you can print the error (in both cases
> actually).
>
> It's probably to specify all this behavior using some kind of default
> finalizer (though you don't have to implement it that way).
Does a default finalizer solve the "event loop does not know its AGs"
problem?
> Hopefully there will be other discussion as well, otherwise I'll have
> to accept the PEP once this issue is cleared up. :-)
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160824/f8e247c3/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4