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

[Nathaniel Smith]

On Nov 26, 2016 2:07 AM, "Alex Grönholm" <alex.gronholm at nextday.fi> wrote:
>
> 26.11.2016, 09:47, Nathaniel Smith kirjoitti:
>>
>> On Fri, Nov 25, 2016 at 10:46 AM, Alex Grönholm <alex.gronholm at nextday.fi>
wrote:
>>>
>>> 25.11.2016, 12:09, Nathaniel Smith kirjoitti:
>>>>
>>>>  On Thu, Nov 24, 2016 at 11:59 PM, Alex Grönholm <
alex.gronholm at nextday.fi> wrote:
>>>>>
>>>>>  25.11.2016, 09:25, Nathaniel Smith kirjoitti:
>>>>>>
>>>>>>  On Thu, Nov 24, 2016 at 1:23 PM, Nathaniel Smith <njs at pobox.com>
wrote: [...]
>>>>>>>>
>>>>>>>>  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.
>>>>>>
>>>>>>  Just pushed async_generator v1.3 to PyPI, with new isasyncgen,
isasyncgenfunction, and (on 3.6) registration with
collections.abc.AsyncGenerator.
>>>>>
>>>>>  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?
>>>>
>>>>  I started doing that, but... it's not an async generator, isasyncgen
is a different inspect function... -n
>>>
>>> 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.
>>
>>  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
>
> 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.

Cool!

> Before I merge this into master, I would like to implement some changes
in your library:
> Set the default value for yield_() argument to None, as in my
yield_async()

Makes sense.

> Add type hints to methods and functions

I haven't had a chance to play with these much, but no objections.

> Look into implementing missing attributes which neither lib had before
(if technically possible): ag_frame, ag_running, ag_code, __name__,
__qualname__

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

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