Support coroutines

[1st1]

Can we add support for coroutine functions? Mainly, I'm curious how we will annotate the return type. We basically have two options:

async def foo() -> typing.Coroutine[str]:
     return 'spam'

or

async def foo() -> str:
     return 'spam'

I'd really prefer the latter style. While the result of 'foo()' is a Coroutine, this is something that type checkers will know without a hint, what really matters is the expected result of await foo() expression.

[vlasovskikh]

The first style is better for asyncio coroutines of Python 3.4. There is typing.Generator type in the PEP 484 parameterized with in- and out- types as well as with the return type of the generator, so the coroutine type could be an alias Coroutine = typing.Generator[Any?, Any?, V_co].

The second style is more convenient for async def functions. We could standardize the type annotation in the context of a async def to have a special meaning: it could be translated by a static checker to Coroutine[...] automatically.

[1st1]

@vlasovskikh I agree.

We also need typing.Awaitable[..], for cases where it is not (or cannot be) specified if we return a coroutine or a future:

def op() -> typing.Awaitable[int]:
     if cond:
          return coro_func()
     else:
          return asyncio.Future(...)

await op() # <- the result is of type int

[gvanrossum]

I like the latter style. I'm labeling this "enhancement" because I don't want this to derail the PEP approval process. FWIW we should distinguish between the return annotation (which can be -> str) and the type of foo() (which should still be Coroutine[str]).

[1st1]

Bumping this issue...

Definitely not a high priority one, but it would be nice if we can have Awaitable and Coroutine types in the typing module.

[gvanrossum]

We will at some time, and we can add it in 3.5.1, but I'm still on vacation
and out of round tuits for another couple of weeks...

[vlasovskikh]

By the way, we discussed the second style of annotating coroutines with Andrew Svetlov at EuroPython. He liked the proposal, it looked natural to him.

[gvanrossum]

Now that Awaitable etc. are in typing.py, is there anything left to do in this project, or is the remaining task supporting async def etc. in mypy? That sounds like it would become fairly straightforward once the fast parser has really landed.

Or do we need language in PEP 484 itself declaring that you should write

async def foo() -> str:
    return ''

(referred to above as "the second style")? If you feel strongly we need PEP language then please propose some prose.

FWIW Larry finally announced the 3.5.2 release schedule.

[ilevkivskyi]

I added PR #225 containing a short subsection discussing generators and coroutines in the PEP 484.

[gvanrossum]

Looks like the PEP work is done here, and so are the additions to typing.py. For mypy there's a separate bug: python/mypy#706

[thehesiod]

if anyone is listening to this thread, this was great for return types, but how about passing an unbound coroutine method as a parameter? From my searching it doesn't seem like there is a way to do it. It's actually a Callable[*]->Awaitable. It sounds like there should be a types.Coroutine. thanks!

ex:

async def dummy(dummy_param: int) -> Awaitable[None]:
    return

async needs_typing(co_method):
    await co_method(1)

await needs_typing(dummy)

[ilevkivskyi]

@thehesiod Yes, and there is an issue for this #251
I hope it will be added soon.