Sorry, but it is still not clear what exactly do you need. If you just want to annotate a function parameter so that arbitrary named tuple can be passed there, then this will be solved by protocols, see #417 and PEP 544 (there are links to implementations for mypy and typeshed). For example something like this:

T = TypeVar('T', bound='NamedTupleProto')

class NamedTupleProto(Protocol):
    _source: str
    _fields: Tuple[str]
    def _asdict(self) -> Dict[str, Any]: ...
    @classmethod
    def _make(cls: Type[T], iterable: Iterable[Any], *,
              new: Any = None, len: int = None) -> T: ...
    def __getitem__(self, item: int) -> Any: ...

def f(arg: NamedTupleProto) -> Dict[str, Any]:
   arg[0]
   return arg._asdict()

class A(NamedTuple):
    a: int
class B(NamedTuple):
    b: int

x: A
y: B
f(x) # OK
f(y) # OK

If you need only some part of the named tuple API, you could define a much simpler protocol.

EDIT: If you need the full named tuple API, then NamedTupleProto should also subclass Sequence (to pull also __len__, __iter__, etc) and declare few other methods (like _replace).

I fear we are comparing an elephant and an ant here.. Anyway to require an user to define an implicit protocol to describe a core library interface does not make a lot of sense.

At the moment I use various workarounds depending on the project, like creating the ABC myself and register my namedtuples manually, or use Any.

What I want to archive is not hard conceptually, NamedTupleType would be used exactly like typing.Tuple, but exposing the NamedTuple API as well. Out of the obvious it would also be a nice place to document namedtuples API incode, and it would probably make the life easier to code checker when accessing namedtuples' public methods .

What I want to archive is not hard conceptually

OK, submit a PR and maybe we'll merge it.

What I want to archive is not hard conceptually

Note that implementing this in typing can be easy, but implementing this in mypy could be much harder. IIUC, essentially, you want a structural subtyping check, which would be just reimplementing protocols for a particular case (you could avoid this by injecting a "fake" nominal supertype during the semantic analysis of named tuples, but this could have other potential problems).

In any case, as Guido mentioned, PRs are welcome.

Okey dokey, I'll work on it during the weekend :)
@ilevkivski I actually was planning of doing that (injection) anyhow let's see.

@ilevkivskyi It may make sense to have NamedTupleProto also define __getattr__, for consistency with __getitem__.

@zauddelig If something like NamedTupleProto is enough for you, you can just define this protocol once in some shared utility module and reuse it everywhere you need it. You can even publish it as a package on PyPI, and if it seems like many users find it useful, we can consider adding it to typing or mypy_extensions. Generally we are reluctant to add a feature (even a simple one) based on a request by a single user, especially if there is a workaround in sight that seems reasonable. Otherwise the static typing APIs will soon become very large and hard to learn, which is something we want to avoid. Each feature has a learning cost associated with it -- even if nobody needs some feature, most users will have to learn enough about the feature to at least be able to decide that it is something that they actually don't need.

@JukkaL

It may make sense to have NamedTupleProto also define __getattr__, for consistency with __getitem__.

Probably. TBH I just picked some random attributes to illustrate the idea, but I rather think this is not the case where "one size fits all". At least it is not completely clear to me what is the "named tuple API".

Generally we are reluctant to add a feature (even a simple one) based on a request by a single user, especially if there is a workaround in sight that seems reasonable.

I think there are at least three users until now who were surprised by this, see also python/mypy#3915.

I think especially because in 3.6 NamedTuples have this nice class syntax. It then really looks like class and so it is surprising that one cannot just use it as a type.

_fields

How can one access the _fields attribute from the namedtuple class itself instead of an instance of it? This protocol does not allow that, and using ClassVar does not seem to typecheck for me (maybe because _fields is read only somehow?).

If this issue is still open, I think it should be reported to bugs.python.org.

Related unmerged mypy PR: python/mypy#11162

It allows to write:

    def deserialize_named_tuple(arg: NamedTuple) -> Dict[str, Any]:
        return arg._asdict()

    Point = namedtuple('Point', ['x', 'y'])
    Person = NamedTuple('Person', [('name', str), ('age', int)])

    deserialize_named_tuple(Point(x=1, y=2))  # ok
    deserialize_named_tuple(Person(name='Nikita', age=18))  # ok

    deserialize_named_tuple((1, 2))  
    # Argument 1 to "deserialize_named_tuple" has incompatible type "Tuple[int, int]"; expected "NamedTuple"

Friendly ping to @JukkaL and @ilevkivskyi 😉