You could create a Protocol that has the tuple operations that you need plus a def __getattr__(self, attr: str) -> Any:. NamedTuple by itself doesn't make sense as a type because it's not actually a type.

Thank you

I found some related issues with info:

• NamedTupleInterface typing#431
• Type variable with NamedTuple as upper bound not working #3915

I think @JelleZijlstra's suggestion is the best realistic solution here :/

Actually, we made a change a while ago that now allows NamedTuple as a type.

Actually, we made a change a while ago that now allows NamedTuple as a type.

Sorry, yes, you're right. This now works — hooray!

from typing import NamedTuple

def func(x: NamedTuple) -> None: ...

class MyTuple(NamedTuple):
    baz: int

func(MyTuple(5))

It's not working as I expect. Since the specific NamedTuple type is unknown, I don't expect attr-defined errors from mypy on attribute access.

def func(x: NamedTuple) -> None:
    y = x.foo  # error: "NamedTuple" has no attribute "foo"

class MyTuple(NamedTuple):
    baz: int

func(MyTuple(5))

Rather, I think what has been implemented so far is attribute checking for known types derived from NamedTuple:

class MyTuple(NamedTuple):
    baz: int

def func(x: MyTuple) -> None:
    y = x.baz
    z = x.bar  # error: "MyTuple" has no attribute "bar"

func(MyTuple(5))

original request:

I'd at least like to specify NamedTuple as a type hint, and have mypy allow any attribute access on top of Tuple operations. The infinitely wider scope of Any isn't too attractive.

As implemented, it's basically a NamedTuple version of object, allowing operations valid on all NamedTuples, while you seem to want a NamedTuple version of Any. That's obviously unsafe and doesn't feel worth an addition to the type system.