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

[Alex Grönholm]

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. 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()
  * Add type hints to methods and functions
  * Look into implementing missing attributes which neither lib had
    before (if technically possible): ag_frame, ag_running, ag_code,
    __name__, __qualname__

I hope these changes aren't too invasive. They should be fully backwards 
compatible.

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