[Async-sig] [ANN] async_generator v1.2 released

Nathaniel Smith njs at pobox.com
Tue Nov 22 18:34:43 EST 2016


On Tue, Nov 22, 2016 at 2:22 PM, Alex Grönholm <alex.gronholm at nextday.fi>
wrote:
> I'm not sure where asyncio_extras's async generator implementation assumes
> you're using asyncio. Could you elaborate on that?

If I'm reading it right, it assumes that the only two things that might be
yielded to the coroutine runner are either (a) the special yield wrapper,
or (b) an awaitable object like an asyncio.Future. This works on asyncio,
because that's all the asyncio runner supports, but it doesn't work with
(for example) curio. async_generator (like native async generators) allows
arbitrary objects to be yielded to the coroutine runner.

> 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.

Yeah, one of the motivations for async_generator has been to figure out
what the semantics for native generators should be :-). The native async
generators in 3.6 use the same implementation trick as async_generator (not
entirely sure if Yury got it from me, or if it's an independent invention),
and the yield from implementation is partly motivated as a proof of concept
/ testing ground for hopefully getting it into 3.7. The yield from
semantics are pretty straightforward though, I think.

> 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?

Makes sense to me :-). I think the obvious approach would be for
async_extras to just depend on async_generator, since AFAICT
async_generator is pretty much complete, and like you say, there's not much
point in carrying around two copies of the same thing. But if you have
another suggestion I'd be interested to hear it...

-n

>
> 22.11.2016, 22:32, Nathaniel Smith kirjoitti:
>
> On Nov 22, 2016 6:22 AM, "Alex Grönholm" <alex.gronholm at 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
>
>

-- 
Nathaniel J. Smith -- https://vorpus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20161122/60b6fad6/attachment-0001.html>


More information about the Async-sig mailing list