Repository navigation
enum auto must not be derived from IntFlag #8286
Description
When using auto enumeration within an class Example(enum.Enum): X = auto(), the invokation of auto() is actually constructing an instance of enum.auto, which just has a default constructor without any extra arguments.
However, when deriving class auto(IntFlag) in enum.pyi the stub actually has a constructor argument of type int, the value for the IntFlag.
This contradicts the definition in the original enum.py implementation.
As a matter of fact this leads to confusing type hints, e.g. enum class auto(IntFlag).
Activity
srittau commentedon Jul 13, 2022
I agree that this is confusing an error prone. In the last few years we tend to align stubs as closely to the implementation as possible. In this case, I believe the best approach is for type checkers would be to special case
auto.That said, as a stop-gap we could try not to derive
autofromIntFlagand copyIntFlags field over, instead or alternatively to just overrideauto.__init__().Type enum.auto according to implementation
srittau commentedon Jul 13, 2022
Also cf. #1331 for PR where the current implementation was added.
ghpqans commentedon Jul 13, 2022
What are you using the
IntFlags's fields for with that original implementation forauto:The derived classes from
EnumMetajust use instances ofclass autoas a reference wrapper. There are no method calls or other attributes to be found.zmievsa commentedon Jul 19, 2022
+1
When working with fastapi, for example, we tend to use a lot of string enums, and we would love to have native support for them and any other types that could possibly use auto.