Enum field 'name' conflics with instance attribute 'name'

[fried]

This is my stub file which I can control.

    class Type(enum.Enum):
        EMPTY = ...
        name = ...       <<<<<<<<
        datasetConfig = ...
        value: int

error: Incompatible types in assignment (expression has type "ellipsis", base class "Enum" defined the type as "str")

The enum is defined as

class Type(enum.Enum):
    EMPTY = 0
    name = 1
    datasetConfig = 2

This is autogenerated code and I don't have control over the enum field names, is there some way for me to have a working stub for this code?

[ethanhs]

Hm, is the stub file a *.pyi file? If not it may be picking up the file as a regular Python module. Otherwise it shouldn't be complaining about Ellipsis.

[fried]

This is a stub, the problem is the stub for Enum says 'name: str' so we are conflicting with that

[ethanhs]

Ah, the source of the issue is https://github.com/python/typeshed/blob/master/stdlib/3.4/enum.pyi#L30 this is a typeshed bug.

It is, in fact not a bug in typeshed.

[fried]

I guess i'm not sure what the fix is, Enum instances do have a .name and .value.

[ethanhs]

I think this does deserve some discussion, and I think considering the trickery of Enum, we might need to modify the stubs and mypy to handle Enum attributes differently from Enum inheriting types themselves. Let me think about this some more.

[gvanrossum]

Yeah, this is tricky. We may have to special-case this in mypy. However maybe @elazarg has an idea, he seems to understand the Enum stuff best.

[elazarg]

Shouldn't the enum attributes be considered implicitly ClassVar[MyEnum]? The base class defines an instance variable, whereas the class defines a class/static variable. It indeed will be special casing.

[ambv]

We looked at this and there's another related issue here. mypy's special handling of Enum already treats name specially. Consider:

class E(enum.Enum):
    one = enum.auto()
    two = enum.auto()
    three = enum.auto()

E.name
E.four

Mypy correctly finds that four is a missing attribute but thinks name does exist. Better yet, if you ask it to reveal its type...

reveal_type(E.name)  # error: Revealed type is 'qwe.E'

This is not a typeshed problem since the revealed type goes against what typeshed defines for name. It's of course fine for valid members:

reveal_type(E.one.name)  # error: Revealed type is 'builtins.str'

[gvanrossum]

I suspect this code is a little lax: https://github.com/python/mypy/blob/master/mypy/checkmember.py#L440