gh-116241: Add support of multiple inheritance with typing.NamedTuple

[serhiy-storchaka]

https://bugs.python.org/issue43923

• Issue: NamedTuple can't inherit from another class #116241

[JelleZijlstra]

I think this goes too far because it's not realistic to expect type checkers to support arbitrary base classes on NamedTuple. Also, there haven't been any user requests that I can see for multiple inheritance with anything other than Generic. So I'd prefer to merge the other PR that allows multiple inheritance with Generic only.

[AlexWaygood]

I think this goes too far because it's not realistic to expect type checkers to support arbitrary base classes on NamedTuple. Also, there haven't been any user requests that I can see for multiple inheritance with anything other than Generic. So I'd prefer to merge the other PR that allows multiple inheritance with Generic only.

I also think it makes sense to only allow multiple inheritance with Generic, for now. It's a smaller change; and, there should be opportunity to rethink it in the future if it turns out that people really need arbitrary multiple inheritance for whatever reason.

[gvanrossum]

So, let's just close this?

[Jason-Y-Z]

people really need arbitrary multiple inheritance for whatever reason

Thanks for reopening! This looks like the case now indeed

[CoolCat467]

Looks great! I ended up doing nearly exactly the same thing in some code of my own to get around this limitation.

[serhiy-storchaka]

Thank you @AlexWaygood and @gvanrossum. Updated to 3.14 and applied the suggestions.

[AlexWaygood]

Given that we've had multiple requests for this, I'm okay with landing it. But please get sign-offs from @gvanrossum and @JelleZijlstra before merging.

[gvanrossum]

Let's do it! (I approve of the idea, I haven't carefully reviewed the code.)

[JelleZijlstra]

I'm OK with this given the discussion on the issue; will take another look at the code soon.

[hugovk]

Reminder for this: the 3.14 beta freeze is in two weeks.

[johnslavik]

I found

>>> from typing import NamedTuple ... ... classFoo(NamedTuple): ... x: int ... ... classBar(NamedTuple, Foo): ... y: int

which fails with

Traceback (most recent call last): File "<python-input-1>", line 6, in <module> class Bar(NamedTuple, Foo): y: int File "/home/bswck/Python/cpython/Lib/typing.py", line 2938, in __new__ nm_tpl.__bases__ = bases ^^^^^^^^^^^^^^^^ TypeError: Cannot create a consistent method resolution order (MRO) for bases tuple, Foo 

Side note

(Thanks Jelle!)
Outside this PR, on the main branch, the error is

Traceback (most recent call last): File "<python-input-1>", line 6, in <module> class Bar(NamedTuple, Foo): y: int File "/home/bswck/Python/cpython/Lib/typing.py", line 2902, in __new__ raise TypeError( 'can only inherit from a NamedTuple type and Generic') TypeError: can only inherit from a NamedTuple type and Generic 

(not a very great message as well, because Foo could be understood as a NamedTuple type)

If we swap the order of bases, with multiple inheritance the error won't happen

>>> classBar2(Foo, NamedTuple): ... y: int

and the result may be surprising

>>> import inspect ... inspect.signature(Bar2) <Signature (y: int)>

My suggestion is to reiterate python/typing#427 (please check https://github.com/bswck/make-typed-namedtuples-final!) and explicitly prohibit the inheritance of typed namedtuples.

[picnixz]

That'd be great to have. I needed this more than once!

[picnixz]

Suggested change

	.. versionchanged:: 3.14
	.. versionchanged:: next

[johnslavik]

+1

[picnixz]

Maybe add a test to check the order of the members as well when doing unpacking? And maybe test class Z(X, Y, NamedTuple)? (I don't know if this leads to a MRO incompatibilty though)