enum auto must not be derived from IntFlag

[ghpqans]

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).

[srittau]

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 auto from IntFlag and copy IntFlags field over, instead or alternatively to just override auto.__init__().

[srittau]

Also cf. #1331 for PR where the current implementation was added.

[ghpqans]

What are you using the IntFlags's fields for with that original implementation for auto:

_auto_null = object()
class auto:
   """
   Instances are replaced with an appropriate value in Enum class suites.
   """
   value = _auto_null

The derived classes from EnumMeta just use instances of class auto as a reference wrapper. There are no method calls or other attributes to be found.

[zmievsa]

+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.