Document how to import types from stubs #8629
Assignees
Comments
|
Yes, it would be good to document this clearly, as the workaround is not obvious. You can use the same approach used to deal with import cycles: https://mypy.readthedocs.io/en/stable/common_issues.html#import-cycles |
|
@JukkaL I want to contribute to mypy. Could you assign this issue to me? |
|
@kshitij86 Your contribution is welcome! This is now assigned to you. |
|
https://github.com/python/typeshed/blob/master/stdlib/2and3/_typeshed/__init__.pyi#L3-L13 is a good starting point for an explanation. For any types that are only available in stubs, you must do from typing import TYPE_CHECKING
if TYPE_CHECKING:
# <import your stub only type> |
|
@mfarrugi If you want to give it a try you’re welcome. |
hauntsaninja
pushed a commit
to hauntsaninja/mypy
that referenced
this issue
Nov 28, 2020
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.
JukkaL
pushed a commit
that referenced
this issue
Jan 6, 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 <>
ilevkivskyi
pushed a commit
that referenced
this issue
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
I'm currently trying to type an API using the
signalmodule. At some point, we pass a callback that has the typesignal._Handler(see: https://github.com/python/typeshed/blob/master/stdlib/3/signal.pyi#L73), which is not in thesignalmodule, but in typeshed.If I try to import it, I get an error, and I could not find the proper way to do so in the documentation.
The text was updated successfully, but these errors were encountered: