Generic Multiinheritance and MRO ordering

[hmc-cs-mdrissi]

Describe the bug
Generic is a weird super class. The consistent method ordering rule that applies for other superclasses does not apply for generic at runtime and if a child class wants different number of type variables it may need to directly subclass generic too. The error message,

Cannot create consistent method ordering

should not be triggered from Generic.

To Reproduce

from typing import Generic, TypeVar

T1 = TypeVar("T1")
T2 = TypeVar("T2")


class Foo1(Generic[T1]):
    ...


class Foo2(Generic[T1]):
    ...


class Bar1(Generic[T1], Foo1[T1], Foo2[T1]): # E: Cannot create consistent method ordering
    ...


class Bar2(Generic[T1, T2], Foo1[T1], Foo2[T1]): # E: Cannot create consistent method ordering
    ...

Expected behavior
No errors. Bar1 it doesn't really matter as dropping generic has minimal effect I know of. Bar2 does need Generic though and dropping it would change type information for that class.

VS Code extension or command-line
pyright 1.1.216

Additional context
Python has a sad number of edge case typing rules.

[erictraut]

Do you happen to know if this is documented anywhere? Or is this just an undocumented quirk of the CPython implementation?

[hmc-cs-mdrissi]

I think it's in pep 560 and https://www.python.org/dev/peps/pep-0560/#mro-entries this subsection documents mro_entries dunder method used that allows Generic class to work around mro rules. The pep directly mentions one of the reasons for that dunder method is,

Using the method API instead of just an attribute is necessary to avoid inconsistent MRO errors, and perform other manipulations that are currently done by GenericMeta.__new__

Technically I think these dunder method can be used by other classes, so it's possible for a user to define their own class that works around normal mro rules (metaclasses also can be used to hack mro), but pep explicitly says that should not be done outside of typing.py/generics,

NOTE: These two method names are reserved for use by the typing module and the generic types machinery, and any other use is discouraged

This is a small enough edge case that maybe using a type ignore for the class definition line works ok assuming I can still use Bar2 with 2 type arguments and they get passed the right way to Foo1/Foo2. I've only come across this error once. Amusingly in mypy's codebase with Bar1 like example.

This mypy issue discusses pep 560 and its motivations. class_getitem machinery used for generics like list[...] also originated from pep 560.

edit: Oh I just realized I can swap order of generic in list and make things work here.

class Bar2(Foo1[T1], Foo2[T1], Generic[T1, T2]):
    ...

is not a type error. That feels like a good enough solution to me. Unsure if there are other edge cases that matter here.

[erictraut]

Thanks for the pointers. That was a big help.

It turns out that Bar1 and Bar2 in the sample below will not produce a runtime error but Bar3 will.

class Bar1(Generic[T1, T2], Foo1[T1], Foo2[T2]):
    ...

class Bar2(Generic[T1, T2], Foo1[T1], Foo2):
    ...

class Bar3(Generic[T1, T2], Foo1, Foo2): # Error
    ...

This behavior is not clearly documented, but I think I have replicated the implementation details to match the runtime behavior.

This will be included in the next release.

[erictraut]

This is addressed in pyright 1.1.217, which I just published. It will also be included in the next release of pylance.