-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Error when preserving generic type behaviour in subclasses (when not supported at runtime) #8523
Labels
Comments
The relevant error flag is I am actually not totally sure what the best way to handle this is? |
How about this unfortunate hack (that creates another class in the hierarchy unfortunately)
|
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
This is a bug report.
The docs for "Using classes that are generic in stubs but not at runtime" (here) clearly indicate how to subclass classes that are defined to be generic in their stubs but don't actually support generics in their runtime code.
The shown method (conditionally defining a typed subclass) works great when you want to lock the type down in your subclass. However, if you want to maintain the subclass as a generic it does not work (mypy reports an error).
Here is failing case (with
mypy --strict
), where the only variation from the canonical example is using a genericTypeVar
instead of astr
as the type for the Queue:mypy reports an error as follows (when the base is
Queue[_T]
):Note that without
--strict
there is no error (not sure which of the flags causes it).The text was updated successfully, but these errors were encountered: