Unsupported left operand type for | ("auto")

[lambdalisue]

Using enum.auto in enum.Flag which has introduced from Python 3.6 cause the following exception

flag.py|8 error| Unsupported left operand type for | ("auto")

with the following code

from enum import Flag, auto


class Color(Flag):
    RED = auto()
    BLUE = auto()
    GREEN = auto()
    WHITE = RED | BLUE | GREEN  " <-- This line.


if __name__ == '__main__':
    assert not bool(Color.RED & Color.BLUE)
    assert not bool(Color.RED & Color.GREEN)
    assert bool(Color.RED & Color.WHITE)

The | operand is supported in enum.Flag so it seems the definition of auto() should be modified for Python 3.6 and over

Ref:
https://docs.python.org/3.6/library/enum.html#flag

[lambdalisue]

Confirmed by mypy 0.511 with Python 3.6

[mistermocha]

Re-running with 3.6.1 and current git-checked version reproduces the same:

8: error: Unsupported left operand type for | ("auto")

[JelleZijlstra]

Enum is doing some pretty magical things here: the metaclass uses a custom mapping as its class dictionary, and that mapping's __setitem__ special-cases enum.auto objects. You can't really expect a static type checker to understand that without some help.

It's possible that these errors will go away if we make auto inherit from Any in https://github.com/python/typeshed/blob/master/stdlib/3.4/enum.pyi, but that would probably hide some other real bugs. Alternatively, we'd need special casing in mypy itself.

[gnprice]

Thanks for reporting this!

@JelleZijlstra (and someone else but I forget who >_> ) and I chatted about this a bit this morning here at the PyCon sprints.

I think this issue can be handled by making auto in typeshed inherit from enum.Flag -- perhaps better from its subclass enum.IntFlag. That should make all the int-related operators behave correctly on auto-initialized flags. In general, we always prefer to handle these wrinkles through the typeshed stubs where possible, rather than through special-case logic in mypy -- the stubs make it easier for anyone to see what the semantics are, and easier for us to make sure things behave in a reasonable uniform way.

There's the other dimension of special behavior here, which is that a value like Color.RED in the example above should specifically have type Color, not just any Flag. We already have some special handling for this in mypy for Enum in general; if that doesn't already work for enum.Flag, we should fix it so it does. But that will be a separate issue. And we'll still want to handle in typeshed whatever parts of the logic we can handle in typeshed.

[JelleZijlstra]

This should be fixed with python/typeshed#1331 but I can't close issues on this repo.

[gvanrossum]

Presumably if you had included "fixes python/typeshed#1331" in the commit message it would have worked? Anyway, closing manually now.