Repository navigation
Certain multiple inheritance using generic alias errors in 3.13 #112903
Description
Bug report
Bug description:
Below is a simplification of some classes that create the problem:
import typing
K = typing.TypeVar("K")
V = typing.TypeVar("V")
class BaseMap(typing.Mapping[K, V]): ...
class MutableMap(BaseMap[K, V], typing.MutableMapping[K, V]): ...
class MyMap(typing.Dict[K, V], MutableMap[K, V]): ...Just entering these definitions in the REPL causes the error.
The stack trace (with info about variable b):
b=__main__.MutableMap[~V]
type(b)=<class 'types.GenericAlias'>
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
class MyMap(typing.Dict[K, V], MutableMap[V]): ...
File "/home/russell/.pyenv/versions/3.13-dev/lib/python3.13/typing.py", line 1391, in __mro_entries__
return super().__mro_entries__(bases)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
File "/home/russell/.pyenv/versions/3.13-dev/lib/python3.13/typing.py", line 1143, in __mro_entries__
if isinstance(b, _BaseGenericAlias) or issubclass(b, Generic):
~~~~~~~~~~^^^^^^^^^^^^
TypeError: issubclass() arg 1 must be a class
This works "fine" before Python 3.13. If I swap the order of typing.Dict[K, V], MutableMap[V], the error no longer presents on 3.13.
I don't understand enough of intersection of these topics to know if this is now an expected error or something is considered wrong. This does seem related to #103369.
CPython versions tested on:
3.8, 3.9, 3.10, 3.11, 3.12, 3.13, CPython main branch
Operating systems tested on:
Linux
Activity
AlexWaygood commentedon Feb 7, 2024
@serhiy-storchaka, since the direct cause here was #103369 — do you have any opinions on this issue or the proposed fix?
encukou commentedon Feb 8, 2024
What's the best way to get the attention of typing-sig experts?
I can help, but I feel that I'd first need to become a typing expert myself -- a significant investment :)
AlexWaygood commentedon Feb 8, 2024
I think all the people with relevant expertise on this area of code are already subscribed to this issue :) I'd say the active core devs who know this code best at this point are probably Jelle, me, Nikita and Serhiy. @carljm might also have some insight, though!
AlexWaygood commentedon Feb 8, 2024
FWIW, this issue doesn't have much to do with the intricacies of static typing (so most typing-sig experts won't have much to say on it), but it has everything to do with the mechanisms we use to achieve the runtime implementation of typing. https://docs.python.org/3/reference/datamodel.html#object.__mro_entries__, and the references listed at the bottom of the docs for that method, would be the relevant reading required to understand what's going on here, if you are interested in helping :)
The difference between
typing._GenericAliasandtypes.GenericAliascomes down to whether a generic alias is created by machinery internal to thetypingmodule or a builtin PEP-585 alias from outside thetypingmoduleserhiy-storchaka commentedon Feb 8, 2024
Does it work with
dict,collections.abc.Mappingandcollections.abc.MutableMappinginstead oftyping.Dict,typing.Mappingandtyping.MutableMapping? Does it work with mixed types?serhiy-storchaka commentedon Feb 8, 2024
It is weird. It fails for
b = MutableMap, butissubclass(MutableMap, typing.Generic)does not fail, andisinstance(MutableMap, typing.GenericAlias)returns False, so the proposed fix should not work.serhiy-storchaka commentedon Feb 8, 2024
Ah, it is
MutableMap[K, V], notMutableMap.Interesting,
typing.Mapping[K, V])has typetyping._GenericAlias,typing.MutableMapping[K, V])has typetyping._GenericAlias, butBaseMap[K, V]has typetypes.GenericAlias.The simpler way to reproduce the issue is:
serhiy-storchaka commentedon Feb 8, 2024
Other, even simpler, example:
JelleZijlstra commentedon Feb 8, 2024
Thanks @serhiy-storchaka for the simpler examples. They helped me find that the proposed fix is wrong; I commented on the PR.
I think to fix this issue we need to either revert #103369, or add special handling to
issubclass()calls in typing.py so they deal withGenericAliascorrectly.carljm commentedon Feb 8, 2024
We have clearly established for a while now that generic aliases are not types; they have
__mro_entries__so they can be inherited, but otherwise they do not pretend to be types. I don't think we can (or should) backtrack on this position; background on it can be found in #89828. Reverting #103369 is just a very small partial rollback of this position, which just leaves us in an inconsistent state.I do think the
issubclasscall in_BaseGenericAlias.__mro_entries__()is simply buggy as written, and must be protected by a priorisinstance(b, type)check. I put more details of that analysis into a comment on the PR.pythongh-112903: Handle non-types in _BaseGenericAlias.__mro_entries__()
gh-112903: Handle non-types in _BaseGenericAlias.__mro_entries__() (#…
AlexWaygood commentedon Feb 9, 2024
Thanks again @rmartin16 for the early testing, thanks @encukou for bumping the issue (which I'd completely forgotten about!), and thanks @carljm for coming up with a fix!
pythongh-112903: Handle non-types in _BaseGenericAlias.__mro_entries_…