I'm not sure where asyncio_extras's async generator implementation
assumes you're using asyncio. Could you elaborate on that?
Native async generators don't support "yield from" either, so I didn't
try to add that until there's a new PEP that defines its exact
semantics. As for aclose/asend/athrow support, I will have to look into
that.
Could we synchronize the implementations so that they're compatible with
each other? I would've preferred there to be only a single
implementation (asyncio_extras was published first, but admittedly I
didn't advertise it that well) but now it'd be best if we work together,
wouldn't you agree?
22.11.2016, 22:32, Nathaniel Smith kirjoitti:
On Nov 22, 2016 6:22 AM, "Alex Grönholm" <alex.gronh...@nextday.fi
<mailto:alex.gronh...@nextday.fi>> wrote:
>
> Does this library offer any advantages over the same functionality
in asyncio_extras?
You would probably know better than me, but last time I looked, the
generator code in asyncio_extras didn't support asend/athrow/aclose,
didn't support yield from, and took shortcuts that assume that you're
using asyncio as your coroutine runner. So I believe async_generator
is more complete and more correct (in the sense that it sticks
strictly to implementing the language level semantics for async
generators without assuming any particular runner).
Of course asyncio_extras has lots of other handy things in it too,
while async_generator is very strictly focused on just this one thing.
(Well, I threw in an implementation of aclosing too, since you can't
really use async generators without it, but that's pretty trivial.) It
might make sense for asyncio_extras to out-source generator handling
to async_generator? Or not.
-n
_______________________________________________
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/
