homepage

> > It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object with an __await__ 
> method.
> 
> "coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require
> "__await__" to be implemented? Maybe even by inheriting from Awaitable?
This is an interesting idea.
Practically, when you register something as a Coroutine, you expect it to
be compatible with ‘await’ expressions. And that’s only possible if
__await__ is implemented.
I’m curious what Guido and Nick think about this. I think that we can
derive Coroutine from Awaitable.
> > Just implement tp_await/__await__ for coroutine-like objects coming from C-API 
> or Cython.
> 
> Sure, that's how it's done. (Specifically, Coroutine is not an
> Iterable/Iterator, but its __await__() returns a thin Iterator that simply
> calls into the Generator code. A bit annoying and slowish, but that's what
> it takes.)
Can't your Coroutine object return itself from its __await__, and implement 
__next__? Like genobject in CPython simply returns self from its __iter__.
> I was just wondering how Cython should compile Python code that makes use
> of this decorator. The Coroutine and Generator types are separated in
> Cython now, and I think that's actually the right thing to do. This
> types.coroutine() decorator and special casing in CPython's code base gets
> a bit in the way here.
I think we can update types.coroutine to continue using CO_ITERABLE_COROUTINE
for pure python generator functions. And for something foreign we can use your
proposed design. Would that be OK?
> 
> > In general, iteration protocol is still the foundation for Future-like objects
> 
> That's not really reflected in the ABCs, is it?
Awaitable has its __await__ defined as a generator...