<p dir="ltr">On Nov 26, 2016 2:07 AM, "Alex Grönholm" <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote:<br>
><br>
> 26.11.2016, 09:47, Nathaniel Smith kirjoitti:<br>
>><br>
>> On Fri, Nov 25, 2016 at 10:46 AM, Alex Grönholm <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote: <br>
>>><br>
>>> 25.11.2016, 12:09, Nathaniel Smith kirjoitti: <br>
>>>><br>
>>>>  On Thu, Nov 24, 2016 at 11:59 PM, Alex Grönholm <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote: <br>
>>>>><br>
>>>>>  25.11.2016, 09:25, Nathaniel Smith kirjoitti: <br>
>>>>>><br>
>>>>>>  On Thu, Nov 24, 2016 at 1:23 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote: [...] <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>
>>>>>>><br>
>>>>>>>  Good point. That should be pretty trivial to add. <br>
>>>>>><br>
>>>>>>  Just pushed async_generator v1.3 to PyPI, with new isasyncgen, isasyncgenfunction, and (on 3.6) registration with collections.abc.AsyncGenerator. <br>
>>>>><br>
>>>>>  And you just *had* to make it incompatible with the async generators from asyncio_extras? "_is_async_gen_function" vs "_is_async_generator"? I thought we agreed on cooperating? <br>
>>>><br>
>>>>  I started doing that, but... it's not an async generator, isasyncgen is a different inspect function... -n <br>
>>><br>
>>> It's an arbitrary string that will likely never be seen by anyone except for people working on the libraries. But it makes a world of difference in compatibility. I named it this way to be consistent with asyncio which marks yield-based coroutines with "_is_coroutine". So please reconsider. <br>
>><br>
>>  Sure, I guess it doesn't matter too much either way. Can we pause a moment to ask whether we really want the two async generator types to return true for each other's introspection function, though? Right now they aren't really interchangeable, and the only user for this kind of introspection I've seen is your contextmanager.py. It seems to use the inspect versions of isasyncgen and isasyncgenfunction, because it wants to know whether asend/athrow/aclose are supported. Right now, if it switched to using async_generator's isasyncgen/isasyncgenfunction, it would continue to work; but if I then switched async_generator's isasyncgen/isasyncgenfunction to detect asyncio_extras's generators, it would stop working again. Speaking of which, what do you want to do about isasyncgen? -n <br>
><br>
> I've created a new branch in asyncio_extras which delegates the implementation of async generators to async_generator. All tests pass with 100% combined coverage.</p>
<p dir="ltr">Cool!</p>
<p dir="ltr">> Before I merge this into master, I would like to implement some changes in your library:<br>
> Set the default value for yield_() argument to None, as in my yield_async()</p>
<p dir="ltr">Makes sense.</p>
<p dir="ltr">> Add type hints to methods and functions</p>
<p dir="ltr">I haven't had a chance to play with these much, but no objections.</p>
<p dir="ltr">> Look into implementing missing attributes which neither lib had before (if technically possible): ag_frame, ag_running, ag_code, __name__, __qualname__</p>
<p dir="ltr">__name__ and __qualname__ are obviously a good idea. The others I'm not so sure about -- I'd worry that anyone who's reaching that deep into the internals is not going to be satisfied by any half-way attempts at compatibility, and it seems unlikely we can achieve detailed compatibility at that level. But maybe it's not that bad; I haven't looked at them in detail. Do you have any particular use cases in mind for them?</p>
<p dir="ltr">-n</p>