Skip to content
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

Clarify "Using types...but not at runtime" docs #15029

Merged

Conversation

jonshea
Copy link
Contributor

@jonshea jonshea commented Apr 10, 2023

The section "Using classes that are generic in stubs but not at runtime" on the runtime_troubles.html page is very helpful, but naive readers who follow its instructions will almost inevitably create a runtime NameError. This PR updates the example to include an annotations import that will avert such a NameError.

The section "Using classes that are generic in stubs but not at runtime" on
the runtime_troubles.html page is very helpful, but naive readers who follow
its instructions will almost inevitably create a runtime `NameError`. This
PR updates the example to include an `annotations` import that will avert
such a `NameError`.
@jonshea jonshea marked this pull request as ready for review April 10, 2023 19:55
Copy link
Collaborator

@hauntsaninja hauntsaninja left a comment

Choose a reason for hiding this comment

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

This looks great, thanks for this PR! Suggested a slightly more concise version

Comment on lines 287 to 292
Note that the ``from __future__ import annotations`` is required to avoid
a ``NameError`` at the use site of the excluded import. In the example above,
``def f(x: SupportsRichComparison)`` would raise ``NameError`` if
``from __future__ import annotations`` is not included. For more information,
and additional caveats, see the section on
:ref:`future annotations <future-annotations>`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Note that the ``from __future__ import annotations`` is required to avoid
a ``NameError`` at the use site of the excluded import. In the example above,
``def f(x: SupportsRichComparison)`` would raise ``NameError`` if
``from __future__ import annotations`` is not included. For more information,
and additional caveats, see the section on
:ref:`future annotations <future-annotations>`.
The ``from __future__ import annotations`` is required to avoid
a ``NameError`` when using the imported symbol.
For more information and caveats, see the section on
:ref:`future annotations <future-annotations>`.

@hauntsaninja hauntsaninja merged commit d328c22 into python:master Apr 11, 2023
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