On June 9, 2015 at 11:11:11 PM, Ben Darnell (report@bugs.python.org) wrote:
[..]
> The type of the callable matters for the types.coroutine decorator. In
> order to get a coroutine object instead of a generator object, I must apply
> types.coroutine to the actual underlying generator, and not any wrapper.

I get it now, thanks for explaining.

FWIW, I’ve recently updated types.coroutine:
https://github.com/python/cpython/blob/eae2bd7c0718b8e4333bd16134e37810e32c050c/Lib/types.py#L164

Instead of unwrapping the callable, it wraps its result with a special
object with __await__.  For instance, this enables regular functions
(not generator functions) that are decorated with @types.coruoutine and
return a generator, or a generator-like object compiled with Cython
to work with ‘await’.  Maybe this is something you can use in Tornado?
There is also issue24325 — to implement most of types.coroutine in C
to make it faster.

> I understand that yield-based coroutines can be confusing, but is this
> particular kind of confusion bad enough that if someone writes 'await
> fibonacci_generator()' we have to raise "TypeError: object generator can't
> be used in 'await' expression" instead of "RuntimeError: Task got bad
> yield: 1"? (that error message from asyncio could definitely be improved,
> but the fact that no one has improved it suggests that the problem isn't
> that severe)
>  
> My goal here is to make it possible for Tornado applications running on 3.5
> to use 'async def' and 'await' even though Tornado itself must remain
> compatible with 2.7 (as do many of the libraries that make up the Tornado
> ecosystem; I don't want libraries to have to update for compatibility with
> this feature). This is doable (I think) but non-trivial in the current
> design; making all generators awaitable would make it easier.

I understand.  My line of thoughts here is: we are introducing a new 
operator.  However we define it now, will be set in stone after 3.5 is
released.  We should try to solve possible backwards compatibility
issues without making its semantics less strict just to make things
easier.

Please take a look at the recently refactored types.coroutine
(there is a link above).