Yes, please start a thread in the discussion forum. I don't think these changes will be controversial, but we should let the community weigh in.

Postedhttps://discuss.python.org/t/adding-namedtuple-member-naming-rules-to-the-typing-spec/88882

Hi, I'm not sure if this is the right place for this discussion—if not, please let me know (and sorry!).

I originally raisedthis issue in pyright, but I think here might be a more appropriate place to discuss it.

Suppose I do have members that start with"_":

NT5=namedtuple("NT5", ["abc","_1"],rename=True)# OKNT5(abc="",_1=1)# OK

How can I provide type annotations for them in a.pyi file?

classNT5(NamedTuple):abc:str_1:int# <- HOW ?

• Can we allow an exemption for field names matching the pattern_{index} (e.g.,_1)?

• Or, could the spec recommend that even if a type checker rejects a field name like_1, it should still provide type analysis for that field:

  fromcollectionsimportnamedtuplefromtyping_extensionsimportTYPE_CHECKING,NamedTuple,assert_typeifnotTYPE_CHECKING:NT5=namedtuple("NT5", ["abc","_1"],rename=True)# OKelse:classNT5(NamedTuple):abc:str_1:int# type: ignore#        #  ^ suppress false positivent5=NT5(abc="",_1=1)# should be okassert_type(nt5[0],str)assert_type(nt5[1],int)# should be okassert_type(nt5.abc,str)assert_type(nt5._1,int)# should be ok

  Currently, mypy and pyrightbehave differently on this point.

I'm with Eric on the linked issue that this doesn't make sense to support. If you use different types on both arms ofif TYPE_CHECKING, you'll see things like this happen.

Can we allow an exemption for field names matching the pattern_{index} (e.g.,_1)?

No, unless the runtime has that exemption. We should match the runtime behavior.

could the spec recommend that even if a type checker rejects a field name like_1, it should still provide type analysis for that field

Type checkers could do that but I don't think it should be the spec's business to decide how type checkers should proceed once they've detected a type error.

And to give a constructive suggestion for your use case: Maybe just don't use namedtuple? If you require names that start with an underscore, it's not the right tool for the job.

Fair enough! Thanks for your quick response! 👍

No, unless the runtime has that exemption

It would be nice iftyping.NamedTuple also supported arename=True option at runtime (I think that's outside the scope of this issue discussion 😂).

And to give a constructive suggestion for your use case: Maybe just don't use namedtuple? If you require names that start with an underscore, it's not the right tool for the job.

I can't control the code on the other end; I can only provide type annotations for it (like in a.pyi file).

The workaround I've come up with for now is:

classNT5(tuple[str,int]):abc:str_1:int__match_args__= ("abc","_1")def__new__(cls,abc:str,_1:int)->Self: ...

But this isn't as straightforward astyping.NamedTuple.

Anyway, thanks for your help! 🙏

The change looks good to me, but you'll need to update the branch, resolve merge conflicts, and re-run the tests with the latest versions of the type checkers.

Thanks for the contribution!

Ok, I've rebased and updated the results.

The PR looks good to me, but we need to wait for@carljm and@JukkaL to review and sign off on the changehere.