Stefan Behnel added the comment:
> Can't your Coroutine object return itself from its __await__, and implement
> __next__? Like genobject in CPython simply returns self from its __iter__.
That was my first try, sure, and it mostly worked. It has a drawback,
though: it's an incomplete implementation of the Iterator protocol. It's
still (mostly) an Iterator, but not an Iterable, so it depends on how you
use it whether you notice or not, and whether it works at all with other
code or not. There's a test for a failing "next(coro)" in your test suite,
for example, which would then not fail in Cython. OTOH, code cannot assume
that calling iter() or for-looping over on an Iterable is a sane thing to
do, because it doesn't work for Python's generator type based coroutine
either, so we might get away with it...
All of these little details make this trick appear like a potential source
of subtle inconsistencies or incompatibilities. But given that there will
almost certainly remain inconsistencies for compiled Python code, I'm not
sure yet which approach is better. It's not impossible that I'll end up
going back to the original design. I guess I'll eventually have to include
some benchmarks in the decision.
On a related note, my testing made me stumble over this code in
asyncio.tasks.Task():
if coro.__class__ is types.GeneratorType:
self._coro = coro
else:
self._coro = iter(coro) # Use the iterator just in case.
This seems wrong regardless of how you look at it. And it definitely fails
with both designs.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24017>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
