Open gwk opened 6 years ago
It seems we miss this case in check_namedtuple_classdef
here: https://github.com/python/mypy/blob/master/mypy/semanal_namedtuple.py#L57. I believe we would also need to handle adding this class to the generated typeinfo. @gwk would you be interested in trying to fix this?
I'm not sure we should support this. Defining a class inside a NamedTuple class doesn't seem like the intended usage of NamedTuple.
I'm not sure we should support this.
I'm okay with that too. I agree it doesn't make a lot of sense in this context.
I'm a little surprised that you would deem legal usage undesirable so quickly.
Nested classes are a feature of the language that can be used in a variety of ways. NamedTuple is a way of conveniently generating classes with certain very desirable properties, namely immutability and sequential access. These two features compose well in Python, and for Mypy to prohibit that composition just makes Mypy less useful.
In my own humble opinion, "Intended usage" is perhaps not the only way that Mypy should consider the language. The language designers have not and cannot predict all of the ways that various features will be productively used or can interact with each other. I would think that the goal of the type checker is to prohibit pathological cases, and not ones that users are reporting as useful!
In any case, thank you for considering this. @ethanhs if I'm really the only one who sees value in this, I could take a stab at a patch.
If you're looking for a concrete use case, here's where I just hit this:
class PR(NamedTuple):
date: datetime.date
link_text: str
link_url: str
title: str
class PRDisplay(NamedTuple):
date: str
link: str
title: str
@property
def display(self) -> 'PR.PRDisplay':
return PR.PRDisplay(
self.date.isoformat(), f'[{self.link_text}]', self.title,
)
Regarding
Defining a class inside a NamedTuple class doesn't seem like the intended usage of NamedTuple.
-- @JelleZijlstra
I agree. The docs say that typing.NamedTuple
is a "Typed version of collections.namedtuple()". collections.namedtuple
does not allow nested classes, so I guess neither should typing.NamedTuple
(at least in a type-checking context).
(Sorry for being late to the party, but I stumbled across a similar use case.)
Nested collections.namedtuple are possible and do happen in some libraries like here. That's main reason I hit this issue and made a pr to support.
A secondary reason to support is consistency with other type checkers. pyright supports nested namedtuples and pytype also seems fine with them.
I think I've found a bug in NamedTuple handling:
This runs fine in Python3.7 but mypy master head issues the following error:
setup.cfg: