Certain multiple inheritance using generic alias errors in 3.13

[rmartin16]

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

Linked PRs

• gh-112903: Fix MRO resolution for GenericAlias types #112926
• gh-112903: Handle non-types in _BaseGenericAlias.__mro_entries__() #115191

[sobolevn]

Hm. Looks like this can fix it:

        for b in bases[i+1:]:
            if (
                isinstance(b, (_BaseGenericAlias, types.GenericAlias)) 
                or issubclass(b, Generic)
            ):
                break

I will try to experiment with the fix a bit more to find if it is correct / full.

[JelleZijlstra]

@rmartin16 thanks for the early testing of Python 3.13! It's very helpful.

And thanks @sobolevn for working on a fix.

[AlexWaygood]

I'm marking this as a release blocker as it's a backwards-incompatible change that's new in Python 3.13 (@Yhg1s, please remove the label if you disagree!)

[encukou]

I don't see the backwards incompatibility. It's a regression in main, but it seems that a fix is ready to go in the next Alpha.
Can it be merged, or is there something I don't see that would require the RM's input?