26.11.2016, 17:42, Nathaniel Smith kirjoitti:
On Nov 26, 2016 2:07 AM, "Alex Grönholm" <alex.gronh...@nextday.fi
<mailto:alex.gronh...@nextday.fi>> wrote:
>
> 26.11.2016, 09:47, Nathaniel Smith kirjoitti:
>>
>> On Fri, Nov 25, 2016 at 10:46 AM, Alex Grönholm
<alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote:
>>>
>>> 25.11.2016, 12:09, Nathaniel Smith kirjoitti:
>>>>
>>>> On Thu, Nov 24, 2016 at 11:59 PM, Alex Grönholm
<alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote:
>>>>>
>>>>> 25.11.2016, 09:25, Nathaniel Smith kirjoitti:
>>>>>>
>>>>>> On Thu, Nov 24, 2016 at 1:23 PM, Nathaniel Smith
<n...@pobox.com <mailto:n...@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
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
