-
-
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
Find consensus around partially concretizing classes with multiple generic parameters #1304
Comments
Since the PEP actually allows this, I'm not sure this needs a PEP change (though it definitely needs a change to typing.py). What will need either a PEP change or a mypy change is the question whether a generic class must include Generic[...] in its direct bases. Mypy currently requires this; the PEP doesn't. One possibility is to update PEP and typing.py to do what mypy currently does. We'll update the PEP to require Generic[...] in the direct bases. We'll update typing.py to require this too, and to allow the example David gives above (and other examples). Another possibility is to keep the PEP unchanged, change mypy to allow omitting Generic[...] if it's unambiguous, and change typing.py to actually support what the PEP says. But the example of class C at python/typing#85 (comment) suggests it's not as simple as the PEP's examples make it seem, and always requiring Generic[...] would avoid the ambiguities. (Note: that comment is in the wrong issue. But it's all related, and it's all a mess, for which my apologies.) Or we could split the difference and allow omitting Generic[...] only if some simple rule is satisfied, e.g. single inheritance from a generic base class with each parameter position being either a plain type variable or a fully concrete type while requiring Generic[...] to disambiguate cases like the above-mentioned class C. I think this is what #302 proposes. |
I added my thoughts to python/typing#85. |
I fixed this in typing.py to support the most generous interpretation of the PEP. I think mypy already supports that. So closing. |
Partially filling in generic parameters in a subclass results in a runtime type error, even though the PEP says it should be allowed. For example:
results in
This probably requires a change to the standard library
typing.py
, but I'm making the issue here so we remember to follow up. See python/typing#115 for earlier discussion.The text was updated successfully, but these errors were encountered: