NamedTuple subclass class objects do not pass check_argument_types for "Type[BaseClass]"

[zbentley]

Describe the bug
Given a parent class "Foo" and a subclass "Bar" which also subclasses NamedTuple, typeguard fails to validate "Bar" for the annotation Type[Foo].

To Reproduce

from typing import NamedTuple, Type
from typeguard import check_argument_types

class Foo(NamedTuple):
	field: int

class Bar:
	...

class Baz(Bar, NamedTuple):
	field: int


def test1(arg: Type[Foo]):
	check_argument_types()

def test2(arg: Type[Bar]):
	check_argument_types()

test1(Foo)
test2(Bar)
test2(Baz)

Expected behavior
All three test calls should pass.

Additional context

Subclassing NamedTuple is dicey and not recommended, but it works OK if your superclass doesn't add any fields (just behavior), so this is a semi-reasonable use case.

[agronholm]

How am I supposed to get the type information to pass these? The superclasses don't show up in either mro() or __bases__. They just show as inheriting directly from tuple.

[zbentley]

That's a good question. I'm not sure; you can introspect that it's a namedtuple by checking cls.__new__'s docstring and repr.

Checking the parent hierarchy is where it gets weird:

In 3.7, I don't think you can do this. This line seems to effectively strip out the real class hierarchy such that a brand new NamedTuple gets constructed.

In py3.9+ (via this PR), I think this information is preserved in __bases__, see this line.

If indeed this works on 3.9+, what would you think about adding this to typeguard with something (docstring? warning?) indicating that it only works on py3.9+?

[agronholm]

The example script does not run at all on Python 3.10 (TypeError: Multiple inheritance with NamedTuple is not supported). If I remove NamedTuple from the declaration of Baz, the tests pass as-is on latest master. So, I don't think there's anything to do, is there?

[zbentley]

If they fixed the ability to even do this at all in 3.10, then yep, this should be considered resolved! Sorry for the issue-report noise, I only had a Py3.7 environment to test against so wasn't aware of the new fixes for this pattern as a whole.