<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
26.11.2016, 17:42, Nathaniel Smith kirjoitti:<br>
<blockquote
cite="mid:CAPJVwB=D8HhWSqRxmo50rSeg35tMwfGMx2ZjGw==vy4-m4AxPA@mail.gmail.com"
type="cite">
<p dir="ltr">On Nov 26, 2016 2:07 AM, "Alex Grönholm" <<a
moz-do-not-send="true" 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
moz-do-not-send="true" 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
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).<br>
<br>
I'll send you a PR when I get around to it.<br>
<blockquote
cite="mid:CAPJVwB=D8HhWSqRxmo50rSeg35tMwfGMx2ZjGw==vy4-m4AxPA@mail.gmail.com"
type="cite">
<p dir="ltr">-n</p>
</blockquote>
<br>
</body>
</html>