New rule proposal: Require enum type

[gitpushdashf]

I haven't seen any existing Python linters doing this, but it seems like a useful rule.

If using say FastAPI, one may want to have an enum like so:

class Color(Enum):
    red = "red"
    green = "green"
    blue = "blue"

This appears fine, and even mypy --strict doesn't mind. But one will find that the Enum doesn't show up correctly in the generated OpenAPI spec + Swagger documentation. FastAPI recommends, instead, doing class Color(str, Enum), and all works fine after that. But it's easy to forget as it will run/behave fine otherwise.

Another thing, as of Python 3.11, is StrEnum. Which I guess is effectively the same as (str, Enum).

This is particularly important if you're using a database, as the database terms for (Enum) vs (str, Enum) can be different and require migrations if you ever try to fix this in the future.

I know some people may want mixed type Enums and this rule probably shouldn't be on by default, but it could be very handle for some. I imagine (StrEnum) would pass, (str, Enum) would pass (or maybe get automatically upgraded to (StrEnum) on Python 3.11+, and (Enum) would fail.

Hopefully this makes sense. Let me know if this seems useful, if there's interest, etc.

[dhruvmanila]

There's a subtle difference between (str, Enum) and StrEnum which is also mentioned in What's new in Python 3.11.:

Using Python 3.11:

from enum import Enum, StrEnum


class Foo(str, Enum):
    SOME = "some"
    OTHER = "other"


class Bar(StrEnum):
    SOME = "some"
    OTHER = "other"

# In [6]: str(Foo.SOME)
# Out[6]: 'Foo.SOME'

# In [7]: str(Bar.SOME)
# Out[7]: 'some'

# In [12]: f"{Foo.SOME} vs {Bar.SOME}"
# Out[12]: 'Foo.SOME vs some'

Also, there's a difference between 3.10 and 3.11 for (str, Enum) for the Enum.__format__ method

Using Python 3.10:

from enum import Enum, StrEnum


class Foo(str, Enum):
    SOME = "some"
    OTHER = "other"

# In [5]: str(Foo.SOME)
# Out[5]: 'Foo.SOME'

# In [7]: f"{Foo.SOME}"
# Out[7]: 'some'

[gitpushdashf]

That is good to know, thank you!

[cleder]

This sounds like a great idea for refactoring legacy code

[charliermarsh]

We're adding this as UP042: #10713