<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
23.11.2016, 01:34, Nathaniel Smith kirjoitti:<br>
<blockquote
cite="mid:CAPJVwBn3tZaYn_j5zS+of1yRnuwzovo07Eqrbr72C844-favLg@mail.gmail.com"
type="cite">
<p dir="ltr">On Tue, Nov 22, 2016 at 2:22 PM, Alex Grönholm <<a
moz-do-not-send="true" href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>>
wrote:<br>
> I'm not sure where asyncio_extras's async generator
implementation assumes<br>
> you're using asyncio. Could you elaborate on that?</p>
<p dir="ltr">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.</p>
</blockquote>
You are misreading the code. It is in no way limited to what asyncio
accepts. It doesn't even import asyncio in the asyncyield or
generator modules. The only parts of the library that depend on PEP
3156 event loops are the ones that involve executors and threads.<br>
<blockquote
cite="mid:CAPJVwBn3tZaYn_j5zS+of1yRnuwzovo07Eqrbr72C844-favLg@mail.gmail.com"
type="cite">
<p dir="ltr">> Native async generators don't support "yield
from" either, so I didn't try<br>
> to add that until there's a new PEP that defines its exact
semantics.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> As for<br>
> aclose/asend/athrow support, I will have to look into that.<br>
><br>
> Could we synchronize the implementations so that they're
compatible with<br>
> each other? I would've preferred there to be only a single
implementation<br>
> (asyncio_extras was published first, but admittedly I
didn't advertise it<br>
> that well) but now it'd be best if we work together,
wouldn't you agree?</p>
<p dir="ltr">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...</p>
</blockquote>
I may consider that at some point, but I'm not yet comfortable with
those extended capabilities. Meanwhile I will add any missing
functionality (asend, athrow etc.) to mine.<br>
<br>
One thing I noticed is that there seems to be no way to detect async
generator functions in your implementation. That is something I
would want to have before switching.<br>
<blockquote
cite="mid:CAPJVwBn3tZaYn_j5zS+of1yRnuwzovo07Eqrbr72C844-favLg@mail.gmail.com"
type="cite">
<p dir="ltr">-n</p>
<p dir="ltr">><br>
> 22.11.2016, 22:32, Nathaniel Smith kirjoitti:<br>
><br>
> On Nov 22, 2016 6:22 AM, "Alex Grönholm" <<a
moz-do-not-send="true" href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>>
wrote:<br>
>><br>
>> Does this library offer any advantages over the same
functionality in<br>
>> asyncio_extras?<br>
><br>
> You would probably know better than me, but last time I
looked, the<br>
> generator code in asyncio_extras didn't support
asend/athrow/aclose, didn't<br>
> support yield from, and took shortcuts that assume that
you're using asyncio<br>
> as your coroutine runner. So I believe async_generator is
more complete and<br>
> more correct (in the sense that it sticks strictly to
implementing the<br>
> language level semantics for async generators without
assuming any<br>
> particular runner).<br>
><br>
> Of course asyncio_extras has lots of other handy things in
it too, while<br>
> async_generator is very strictly focused on just this one
thing. (Well, I<br>
> threw in an implementation of aclosing too, since you can't
really use async<br>
> generators without it, but that's pretty trivial.) It might
make sense for<br>
> asyncio_extras to out-source generator handling to
async_generator? Or not.<br>
><br>
> -n<br>
><br>
></p>
<p dir="ltr">-- <br>
Nathaniel J. Smith -- <a moz-do-not-send="true"
href="https://vorpus.org">https://vorpus.org</a></p>
</blockquote>
<br>
</body>
</html>