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

Error when preserving generic type behaviour in subclasses (when not supported at runtime) #8523

Closed
rwarren opened this issue Mar 11, 2020 · 2 comments · Fixed by #9763
Closed

Comments

@rwarren
Copy link

rwarren commented Mar 11, 2020

This is a bug report.

  • mypy = 0.770
  • python = 3.8.2
  • I did not try running mypy from git master

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 generic TypeVar instead of a str as the type for the Queue:

from queue import Queue
from typing import TYPE_CHECKING, TypeVar

_T = TypeVar("_T")
if TYPE_CHECKING:
    MyQueueBase = Queue[_T]  # change _T to str here and it works perfectly (per the docs)
else:
    MyQueueBase = Queue
class MyQueue(MyQueueBase): pass  # mypy error is on this line (9)

mypy reports an error as follows (when the base is Queue[_T]):

$ python --version
Python 3.8.2
$ mypy --version
mypy 0.770
$ mypy --strict ./generic_subclass_example.py 
generic_subclass_example.py:9: error: Missing type parameters for generic type "MyQueueBase"
Found 1 error in 1 file (checked 1 source file)

Note that without --strict there is no error (not sure which of the flags causes it).

@msullivan
Copy link
Collaborator

The relevant error flag is --disallow-any-generics.

I am actually not totally sure what the best way to handle this is?

@msullivan
Copy link
Collaborator

How about this unfortunate hack (that creates another class in the hierarchy unfortunately)

from queue import Queue
from typing import TYPE_CHECKING, TypeVar, Generic

_T = TypeVar("_T")
if TYPE_CHECKING:
    class MyQueueBase(Queue[_T]): pass
else:
    class MyQueueBase(Generic[_T], Queue): pass

class MyQueue(MyQueueBase[_T]): pass

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
Projects
None yet
2 participants