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