``auto`` for ``StrEnum`` is incorrectly subclassing ``IntFlag``

[DanielNoord]

from enum import StrEnum, auto
from typing import reveal_type


class Test(StrEnum):
    test = auto()


print(type(Test.test.value))


def func(x: Test):
    print(reveal_type(x.value))


func(Test.test)

On 3.11 this returns:

❯ python test.py
<class 'str'>
Runtime type is 'str'
test

However, both pyright and mypy reveal the type as being int because of:

typeshed/stdlib/enum.pyi

Lines 289 to 290 in 201940c

	# subclassing IntFlag so it picks up all implemented base functions, best modeling behavior of enum.auto()
	class auto(IntFlag):

This was introduced all the way back in #1331.

Well it might be "mostly" correct, with StrEnum this is clearly false and leads to cases where we couldn't use StrEnum without adding type: ignores anyway.
I don't really know what the appropriate fix is so I sadly can't contribute one.

[srittau]

Our annotations of auto() predate StrEnum, and the current hack used to work (and still works) for the other enum types. But due to the highly dynamic nature of auto (and enums in general), this is something that should be implemented in the type checkers. typeshed's hack doesn't work anymore.

In light of the introduction of StrEnum and to prevent backwards incompatibilities, I think the best way forward is to ask type checker implementors to special case auto() and then eventually drop our hack from typeshed.

Cc @ilevkivskyi @JukkaL @erictraut for awareness.

[sobolevn]

I can add a plugin for this to mypy tomorrow :)