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

[Alex Grönholm]

26.11.2016, 17:42, Nathaniel Smith kirjoitti:
>
> On Nov 26, 2016 2:07 AM, "Alex Grönholm" <alex.gronholm at nextday.fi 
> <mailto: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 <mailto: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 <mailto: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 <mailto: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?
>
I don't have a particular use case in mind, I'm just looking for 
completeness. They're right in the spec and I believe simple getters 
should do just fine (coroutines should have matching attributes which 
can be used directly).

I'll send you a PR when I get around to it.
>
> -n
>

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