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

[Nathaniel Smith]

On Nov 23, 2016 11:29 PM, "Alex Grönholm" <alex.gronholm at nextday.fi> wrote:
>
> 23.11.2016, 01:34, Nathaniel Smith kirjoitti:
>>
>> 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.
>
> 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.

I didn't say that it imported asyncio. I said that it assumes the only
things that will be yielded are the things that asyncio yields. This is the
line that I'm worried about:


https://github.com/agronholm/asyncio_extras/blob/aec412e1b7034ca3cad386c381e655ce3547fee3/asyncio_extras/asyncyield.py#L40

The code awaits the value yielded by the coroutine, but there's no
guarantee that this value is awaitable. It's an arbitrary Python object
representing a message sent to the coroutine runner. It turns out that
asyncio only uses awaitable objects for its messages, so this code can get
away with this on asyncio, but if you try using this code with curio then
I'm pretty sure you're going to end up doing something like "await (3,)"
and then blowing up.

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

You could just not import yield_from_ and then you don't have any extended
capabilities... but up to you, obviously.

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

Good point. That should be pretty trivial to add.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20161124/93155241/attachment.html>