This needs a backport to 3.12 and 3.13.

Changed my mind, let's not backport it :)
Thanks@ZeroIntensity and@JelleZijlstra for convincing me this.

1. If we backport this, users can start relying onsuper() working in typed namedtuples in versions ~=3.12.9 and ~=3.13.2 in libraries. That would cause other users (>=3.12.0,<3.12.9; >=3.13.0,<3.13.2) to get hit with this strange error message, and no hint on how to fix it. A way to navigate this is distribute the bugfix withtyping_extensions.NamedTuple to allow gradual introduction, but library maintainers would have to know it up front to not rely ontyping.NamedTuple directly in 3.12-3.13 and instead usetyping_extensions.NamedTuple, which kills the point of backporting this if we can just add this functionality totyping_extensions and not backport anything in cpython itself.

2. A potential to break a vague usage we don't know of. I don't see it an appealing argument, but OTOH I seepeace of mind a good argument.

CPython disallows

classFoo:__classcell__=None

but this implementation allows

fromtypingimportNamedTupleclassFoo(NamedTuple):__classcell__=None

should I pop from the origin class namespace with a sentinel object fallback instead ofNone?
So that we let the error propagate if someone sets__classcell__ toNone explicitly.

Errors should never pass silently, unless explicitly silenced.

Ideally I feel like this fix would not involve adding a new parameter tocollections.namedtuple(), since this issue only really affectstyping.NamedTuple. However, I can't see another solution to the problem. I suppose the other option would be just to document thatsuper() doesn't work inside methods ontyping.NamedTuples created using the class syntax.

should I pop from the origin class namespace with a sentinel object fallback instead ofNone?
So that we let the error propagate if someone sets__classcell__ toNone explicitly.

It seems like an unlikely situation, but I suppose this would be strictly-speaking more correct!

I like@ZeroIntensity's idea of movingcollections.namedtuple tocollections._namedtuple, adding the param tocollections._namedtuple, and then wrapping it in a newcollections.namedtuple with the original signature preserved, without the_classcell param.

oh, except some tests are failing

oh, except some tests are failing

Hah! How ignorant of me.

I added another frame by wrapping the function and didn't fixup the existing frame refs (getframe(1) should becomegetframe(2)) :)

Thanks@AlexWaygood and@ZeroIntensity for working through this and finding a better approach!

One last thought is whether I should test__classcell__ nonsense overwrites errors are preserved intyping.NamedTuple subclasses, as in

@rhettinger Please review. :)

I don't think this is worth it and instead prefer Alex's suggestion "to document that super() doesn't work inside methods on typing.NamedTuples created using the class syntax".

Named tuples are thin classes, there isn't much in the way of reusable code. Likely, that is why overriding rather than extending is the norm. Also dataclasses seem to be preferred when people are trying to do anything more interesting.

I do admire the analysis and effort that was put into this PR. The code looks correct. However, I think almost no one needs this. The edit is a really interesting (and brilliant) but slightly icky magic trick that isn't that easy to explain. Neither_classcell norstackoffset is intrinsic to whatnamedtuple is trying to do. I prefer that they were not there.

FWIW, I'm only-0 on this one. The thought is to avoid janky code and not skate onto thin ice when you don't have to.
.

@rhettinger Thank you. I must say I agree with you for the most part, I also don't feel too strong about the general necessity for this to work, especially sinceNamedTuple subclasses cannot be inherited from. What I'd like to stress though is that IMO we can'tjust document thatsuper() is unsupported intyping.NamedTuple subclasses—the error message is very strange upon using one of the basic features of Python:
__class__ not set defining 'Foo' as <class 'Foo'>. Was __classcell__ propagated to type.__new__?

How about I make a PR to detect classcells and raise a proper, easy to comprehend error message like "using__class__ orsuper() in typed namedtuples is not supported"?
That would touch onlytyping.NamedTuple, addressing the root cause and allowing others to save time and confusion.

How about I make a PR to detect classcells and raise a proper, easy to comprehend error message like "usingclass or super() in typed namedtuples is not supported"?

That would touch only typing.NamedTuple, addressing the root cause and allowing others to save time and confusion.

+1 That would tremendously improve the user experience.

I'm therefore closing this PR and will create another one with the improved error message.

Thank y'all for reviews, this bug was very fun to work on, so no regrets though it didn't make a cut :)