Enum works in python 3.10 breaks in 3.11

[naringas]

Bug report

I have this (simplified) code

from enum import Enum, auto, unique

@unique
class TokenType(Enum):
	# // Single-character tokens.
	LEFT_PAREN = '('
	
	# // Literals.
	IDENTIFIER = auto()
	STRING = auto()
	NUMBER = auto()
	
	# // Keywords.
	AND = 'and'
	
	WHILE = 'while'

	EOF = auto()

I tested this (I developed it) using python 3.10.8.

My friend ran it in 3.11.3 and it breaks like this:

  File ".../3.11.3/lib/python3.11/enum.py", line 1561, in unique
    raise ValueError('duplicate values found in %r: %s' %
ValueError: duplicate values found in <enum 'TokenType'>: NUMBER -> STRING, EOF -> STRING

We can work around the problem using a StrEnum and it's all fine. But I think this is a regression bug. I don't think my code should break like this because the standard library changed.
Also, fyi, StrEnum is new in 3.11 so I cannot just adjust my own code (which works well).

Linked PRs

• [3.12] gh-104271: Fix auto() fallback in case of mixed type Enum #104279
• [3.11] [3.12] gh-104271: Fix auto() fallback in case of mixed type Enum (GH-104279) #104809

[itamaro]

I confirmed the issue and proposed a fix in gh-104279

I think iterating the list of last_values in gh-91457 in sorted order (instead of reversed sorted order) was an oversight

in any case, @naringas, it seems that this use of auto() will be deprecated in 3.13.
you should be able to fix this in your code by overriding _generate_next_value_ to get your desired behavior in a way that works with older python versions.

[naringas]

in any case, @naringas, it seems that this use of auto() will be deprecated in 3.13. you should be able to fix this in your code by overriding _generate_next_value_ to get your desired behavior in a way that works with older python versions.

I think the issue came from how I use Enum with mixed values; I have values either as strings, or 'auto'.

Now that I've had to think about this, I realize expect unique (hence the decorator to error out if this fails) numerical values. I think this is a valid expectation for a unique Enum type with mixed values.

question: this issue gets closed if/when the PR gets merged?

[sunmy2019]

@ethanfurman

[itamaro]

question: this issue gets closed if/when the PR gets merged?

I think so, although it's up to the codeowner (Ethan) to decide if and how this should be fixed

[itamaro]

@ethanfurman what do you think about this issue and proposed fix?

[ethanfurman]

Apologies for the delay, I'll try to get to this this week. In general I agree with the proposed solution.