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

Document PEP 585, 563, 604 and more. #9763

Merged
merged 9 commits into from Jan 6, 2021
Merged

Conversation

hauntsaninja
Copy link
Collaborator

Fixes #8629, fixes #8523

This creates a new page to document issues arising from discrepancies
between the runtime and annotations. I felt this was better, rather than
force-fitting things into existing pages and "common issues", for
instance, it prevents us from having to explain PEP 563 in several
different places.

I do still list the runtime errors you'd get in the "common issues" page
to preserve SEO :-)

"String literal types", "Class name forward references", and "Import
cycles" are basically the same as where they were copied over from.

This also factors out the documentation of PEP 604 that I promised when
merging that PR (it seemed pretty verbose, particularly for the "kinds
of types" page). It's also a good place to document PEP 613, when we get
around to supporting that.

hauntsaninja added 2 commits November 27, 2020 16:23
Fixes python#8629, fixes python#8523

This creates a new page to document issues arising from discrepancies
between the runtime and annotations. I felt this was better, rather than
force-fitting things into existing pages and "common issues", for
instance, it prevents us from having to explain PEP 563 in several
different places.

I do still list the runtime errors you'd get in the "common issues" page
to preserve SEO :-)

"String literal types", "Class name forward references", and "Import
cycles" are basically the same as where they were copied over from.

This also factors out the documentation of PEP 604 that I promised when
merging that PR (it seemed pretty verbose, particularly for the "kinds
of types" page). It's also a good place to document PEP 613, when we get
around to supporting that.
Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

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

These look great! Runtime issues are sometimes painful to deal with, and it's a good to have them all covered in one place. Left a bunch of minor comments (mostly nits).

docs/source/builtin_types.rst Show resolved Hide resolved
three tools at our disposal:

* For Python 3.7 through 3.9, use of ``from __future__ import annotations``
(:pep:`563`), made the default in Python 3.10 and later
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: Since 3.10 is not out yet, this would be better written as "... will be the default in Python 3.10 and later".

docs/source/runtime_troubles.rst Show resolved Hide resolved

Python 3.5.1 and below don't have :py:data:`~typing.TYPE_CHECKING`. An
alternative is to define a constant named ``MYPY`` that has the value
``False`` at runtime. Mypy considers it to be ``True`` when type checking.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe add a short example of how this works here?

docs/source/runtime_troubles.rst Show resolved Hide resolved
docs/source/runtime_troubles.rst Outdated Show resolved Hide resolved
docs/source/runtime_troubles.rst Show resolved Hide resolved
docs/source/runtime_troubles.rst Outdated Show resolved Hide resolved
Using X | Y syntax for Unions
-----------------------------

Starting with Python 3.10 (:pep:`604`), you can spell union types as ``x: int |
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: "... you will be able to spell", since Python 3.10 is not out yet.

docs/source/runtime_troubles.rst Outdated Show resolved Hide resolved
@hauntsaninja
Copy link
Collaborator Author

Thanks, made changes everywhere that I marked a conversation as resolved. The two things I haven't done are:

  1. changing tense for Python 3.10. I'd prefer not to, since it's an easy way for documentation to end up sounding really out of date. Plus we already have three alphas of 3.10; it'll be upon us before we know it!
  2. adding an example for Python 3.5.1. We're just a release or two away from dropping support for 3.5 altogether; IIRC 3.5.1 doesn't even have typing.overload. If there's another reason to use a MYPY constant, I'd be happy to document it in more detail.
    I don't feel that strongly though, so if you ask again I'll make the changes! :-)

Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

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

Thanks for the updates! Looks good now. I agree with your reasoning, and other changes I proposed aren't important.

@JukkaL JukkaL merged commit 6e8c0cd into python:master Jan 6, 2021
@hauntsaninja hauntsaninja deleted the docs branch January 6, 2021 18:26
ilevkivskyi pushed a commit that referenced this pull request Jan 19, 2021
Fixes #8629, fixes #8523.

This creates a new page to document issues arising from discrepancies
between the runtime and annotations. I felt this was better, rather than
force-fitting things into existing pages and "common issues", for
instance, it prevents us from having to explain PEP 563 in several
different places.

I do still list the runtime errors you'd get in the "common issues" page
to preserve SEO :-)

"String literal types", "Class name forward references", and "Import
cycles" are basically the same as where they were copied over from.

This also factors out the documentation of PEP 604 that I promised when
merging that PR (it seemed pretty verbose, particularly for the "kinds
of types" page). It's also a good place to document PEP 613, when we get
around to supporting that.

Resolves #9856.

Co-authored-by: hauntsaninja <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants