> > 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...