Repository navigation
Enum of a NamedTuple-derived type leads to incompatible type error #1745
Description
This code:
from typing import NamedTuple
from enum import Enum
Foo = NamedTuple('Foo', [('bar', int)])
class MyEnum(Foo, Enum):
CONSTANT = Foo(bar=1)
def f(x):
# type: (MyEnum) -> None
pass
f(MyEnum.CONSTANT)leads to:
error: Argument 1 to "f" has incompatible type "test.MyEnum"; expected "MyEnum"
Activity
gvanrossum commentedon Jun 25, 2016
I know we have plenty of namedtuple-related issues. But does this code serve a real purpose? Enum has a lot of magic, so does namedtuple -- I'm not sure if we should really be required to make sense of this, and what you're trying to accomplishing with that class.
AlexOnAPeak commentedon Jun 28, 2016
This is a distilled example of a real-life enum I came across in our code. Not going to get into whether or not having such an enum is a good idea, but we have it and I'm getting mypy errors trying to use it as an argument to a function. The main weirdness is that the error is of the form
incompatible type: "fully.qualified.path.to.MyEnum"; expected "MyEnum"which seems fishy.gvanrossum commentedon Jun 28, 2016
Note that without the Foo base class you can still access the bar attribute in f() -- use x.value.bar rather than x.bar.
gnprice commentedon Aug 9, 2016
This came up again today -- a user hit an error message just as confusing (and with the same structure) as the one in @alexsydell's report, and after some debugging someone else recognized it as this issue.
In addition to the type-checker issue that we shouldn't be reporting an error here at all, the error message is awfully perplexing and is likely an example of #1582.
elazarg commentedon Sep 5, 2016
I believe that this is a result of the special casing of both
EnumandNamedTuple. It can be special-cased too at subtypes.py:I think that this special casing is justified, but I'm not sure.
Support NamedTuple-derived Enum (#2407)