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.

Sign up for GitHub

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
Merged

Short subsection on annotating coroutines #225

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
43a554b
Short subsection on annotating coroutines
ilevkivskyi May 24, 2016
30ec275
response to comments: clarify Generator params
ilevkivskyi May 24, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions pep-0484.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1015,6 +1015,40 @@ In such cases the default value may be specified as a literal
ellipsis, i.e. the above example is literally what you would write.


Annotating generator functions and coroutines
---------------------------------------------

The return type of generator functions can be annotated by
the generic type ``Generator[yield_type, send_type,
return_type]`` 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.

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():
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)

bar = await spam(42) # type: str

The ``typing.py`` module also provides generic ABCs ``Awaitable``,
``AsyncIterable``, and ``AsyncIterator`` for situations where more precise
types cannot be specified::

def op() -> typing.Awaitable[str]:
if cond:
return spam(42)
else:
return asyncio.Future(...)


Compatibility with other uses of function annotations
=====================================================

Expand Down