Support coroutines

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.

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.

@vlasovskikh

@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

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

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.

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

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.

Wrap the return type from type providers for async function into the …

Add Async classes to typing stub.

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.

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

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

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)

@thehesiod

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

Navigation Menu

Repository navigation

Support coroutines #119

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Support coroutines #119

Description

Activity

vlasovskikh commented on May 20, 2015

1st1 commented on May 20, 2015

gvanrossum commented on May 20, 2015

1st1 commented on Aug 3, 2015

gvanrossum commented on Aug 3, 2015

vlasovskikh commented on Aug 4, 2015

gvanrossum commented on Apr 29, 2016

ilevkivskyi commented on May 24, 2016

gvanrossum commented on Jun 6, 2016

thehesiod commented on Oct 24, 2016

ilevkivskyi commented on Oct 24, 2016

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions