-
Notifications
You must be signed in to change notification settings - Fork 258
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
Conversation
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]: |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
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 |
Actually, |
async def spam(ignored: int) -> str: | ||
return 'spam' | ||
|
||
async def foo(): |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 by
typing.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 ofawait
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)
Finishes #119 , mypy implementation is tracked in python/mypy#1453