[ty] handle more enum.auto() cases

[thejchap]

Summary

see astral-sh/ty#1241

• support .value on single member enums
  • more context in this pr - for single-member enums, the type is an instance of the enum class. for multi-member enums, its a union of literals. handle the former
• handle str, bytes, float as Enum mixins
  • this explicitly checks if the enum is a subclass of any of these and sets the type
• add TODO test for tuple as an Enum mixin

i'm not sure this is the best implementation for auto for these mixin types - at runtime it looks like the counter gets coerced somehow into the mixin type (ie auto() -> (1,) for tuple mixins). could probably handle this in a more generic way but this seems like a decent step for now

Test Plan

new mdtests

[github-actions]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[github-actions]

mypy_primer results

Changes were detected when running on open source projects

django-stubs (https://github.com/typeddjango/django-stubs)
- tests/assert_type/db/models/test_enums.py:194:1: error[type-assertion-failure] Argument does not have asserted type `str`
- Found 468 diagnostics
+ Found 467 diagnostics

No memory usage changes detected ✅

[AlexWaygood]

Thank you!

[AlexWaygood]

hmm, I'm not sure we should be adding more special cases here. An enum class that uses bytes as a mixin isn't conceptually any different from an enum that uses tuple or list or dict as a mixin, or a custom dataclass or custom NamedTuple as a mixin. Why should we treat bytes and float specially here?

Rather than adding more special cases, I think we should have a generalised fallback logic that iterates through the MRO of the enum class to check whether it has a custom mixin that isn't str or int. (Those two make sense to special-case, I think, because of the presence of StrEnum and IntEnum in the stdlib. You can determine whether an element in the MRO is a "custom mixin" class by checking if it isn't object and isn't a subclass of enum.Enum -- if both those conditions hold, I think we can treat it as a mixin class.) If the enum class has a custom mixin and auto() is used to define the value of an enum member, we should probably infer the .value of that enum member as just being Any, which would still be more accurate than what we have on main (even if it isn't very precise!). It seems pretty hard to predict whether the .value property is going to give you an instance of the mixin or an integer:

>>> class Foo: ...
>>> import enum
>>> class FooEnum(Foo, enum.Enum):
...     X = enum.auto()
...     
>>> FooEnum.X.value
1
>>> class BEnum(bytes, enum.Enum):
...     X = enum.auto()
...     
>>> BEnum.X.value
b'\x00'
>>> class TEnum(tuple, enum.Enum):
...     X = enum.auto()
...     
>>> TEnum.X.value
(1,)

[thejchap]

this makes a lot more sense - thanks - didn't feel great about the explicit special cases after going down that road...