Skip to content

Short subsection on annotating coroutines #225

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 24, 2016

Conversation

ilevkivskyi
Copy link
Member

Finishes #119 , mypy implementation is tracked in python/mypy#1453

@ilevkivskyi ilevkivskyi mentioned this pull request May 24, 2016
The return type of generator functions can be annotated by
the generic type ``Generator`` provided by ``typing.py`` module::

def echo_round() -> Generator[int, float, str]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From this example alone it's hard to see how [int, float, str] map to the various aspects of generators. Personally I use the fact that they were introduced historically at different times: yielded value (int), value returned by yield expression (float), value returned by return statement (str). But for others that may not be a great help...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I added the type parameters in a new commit.

@gvanrossum gvanrossum merged commit c532807 into python:master May 24, 2016
@gvanrossum
Copy link
Member

Thanks! I suspect there are still some organizational loose ends, e.g. there's a bullet list somewhere that claims to give everything exported by typing.py but I think we forgot to add some recent additions there.

@ilevkivskyi
Copy link
Member Author

Actually, Generator, Awaitable, AsyncIterable, and AsyncIterator are already in this list. However, ContextManager is not in this list.

async def spam(ignored: int) -> str:
return 'spam'

async def foo():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoa, I think this needs -> None otherwise the body won't be type-checked (despite the presence of type comments).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the initial version I had this -> None, but then removed to simplify the example. If I understand correctly this sentence in the PEP "Any function without annotations should be treated as having the most general type possible, or ignored, by any type checker", then it is up to type-checker whether to type check the body of foo here. I do not have any preference here, if you think it is better to add -> None, then should I make another PR (this one is already merged), of you will add it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just updated the PEP. I think it's better to add, because the only known
example of a type checker does indeed ignore the body of unannotated
functions, so it's better to show examples that are fully annotated (except
when talking about annotated vs. unannotated).

On Thu, May 26, 2016 at 12:37 AM, Ivan Levkivskyi [email protected]
wrote:

In pep-0484.txt
#225 (comment):

+return_type]provided bytyping.py`` module::
+

  • def echo_round() -> Generator[int, float, str]:
  •  res = yield
    
  •  while res:
    
  •      res = yield round(res)
    
  •  return 'OK'
    
    +Coroutines introduced in PEP 492 are annotated with the same syntax as
    +ordinary functions. However, the return type annotation corresponds to the
    +type of await expression, not to the coroutine type::
    +
  • async def spam(ignored: int) -> str:
  •  return 'spam'
    
  • async def foo():

In the initial version I had this -> None, but then removed to simplify
the example. If I understand correctly this sentence in the PEP "Any
function without annotations should be treated as having the most general
type possible, or ignored, by any type checker", then it is up to
type-checker whether to type check the body of foo here. I do not have
any preference here, if you think it is better to add -> None, then
should I make another PR (this one is already merged), of you will add it?


You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/python/typing/pull/225/files/30ec2751a96be037a02879b6c551b7a00d05a596#r64702492

--Guido van Rossum (python.org/~guido)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants