Enum auto() Sequence Interruption Bug

[AvocadoStyle]

When using an Enum with auto() to generate sequential integer values, introducing a member with a non-auto() type (like a str) causes unexpected behavior. Specifically, if a non-auto() member is inserted after the first few auto() members or between them, accessing any members defined with auto() after this insertion consistently returns the value of the third Enum member, regardless of the actual member being accessed.

Example of good behavior

When all Enum members use auto(), they each receive a unique integer value:

from enum import Enum, auto

class SOME_CLS_A(Enum):
    a = auto()
    b = auto()
    c = auto()
    d = auto()
    e = auto()
    f = auto()

print(SOME_CLS_A.a)  # <SOME_CLS_A.a: 1>
print(SOME_CLS_A.b)  # <SOME_CLS_A.b: 2>
print(SOME_CLS_A.c)  # <SOME_CLS_A.c: 3>
print(SOME_CLS_A.d)  # <SOME_CLS_A.d: 4>
print(SOME_CLS_A.e)  # <SOME_CLS_A.e: 5>
print(SOME_CLS_A.f)  # <SOME_CLS_A.f: 6>

As we can see we're getting the values as expected!

Example of bad behavior

from enum import Enum, auto

class SOME_CLS_B(Enum):
    a = auto()
    b = "other type than int or auto"
    c = auto()
    d = auto()
    e = auto()
    f = auto()

print(SOME_CLS_B.a)  # <SOME_CLS_B.a: 1>
print(SOME_CLS_B.b)  # <SOME_CLS_B.b: 'other type than int or auto'>
print(SOME_CLS_B.c)  # <SOME_CLS_B.c: 2>
print(SOME_CLS_B.d)  # <SOME_CLS_B.c: 2>
print(SOME_CLS_B.e)  # <SOME_CLS_B.c: 2>
print(SOME_CLS_B.f)  # <SOME_CLS_B.c: 2>

In this example, all Enum members from c to f unexpectedly refer to the value assigned to SOME_CLS_B.c instead of receiving new, sequential values. This behavior demonstrates the issue when a non-auto() entry is included in the enum.

Example of python3.10 execution of the same "issue" (And it's should be the fix and behave like that):

from enum import Enum, auto

class SOME_CLS_B(Enum):
    a = auto()
    b = "other type than int or auto"
    c = auto()
    d = auto()
    e = auto()
    f = auto()

# Testing outputs
print(SOME_CLS_B.a)  # <SOME_CLS_B.a: 1>
print(SOME_CLS_B.b)  # <SOME_CLS_B.b: 'other type than int or auto'>
print(SOME_CLS_B.c)  # <SOME_CLS_B.c: 2>
print(SOME_CLS_B.d)  # <SOME_CLS_B.d: 3>
print(SOME_CLS_B.e)  # <SOME_CLS_B.e: 4>
print(SOME_CLS_B.f)  # <SOME_CLS_B.f: 5>

CPython versions tested on:

3.11, 3.12, 3.13

Operating systems tested on:

Linux, Windows

[Eclips4]

Hello!
Thanks for the report.
In fact, the second example produces warnings in 3.11-3.12 versions:

/home/eclips4/programming/programming-languages/cpython/example.py:6: DeprecationWarning: In 3.13 the default `auto()`/`_generate_next_value_` will require all values to be sortable and support adding +1
and the value returned will be the largest value in the enum incremented by 1
  c = auto()
/home/eclips4/programming/programming-languages/cpython/example.py:7: DeprecationWarning: In 3.13 the default `auto()`/`_generate_next_value_` will require all values to be sortable and support adding +1
and the value returned will be the largest value in the enum incremented by 1
  d = auto()
/home/eclips4/programming/programming-languages/cpython/example.py:8: DeprecationWarning: In 3.13 the default `auto()`/`_generate_next_value_` will require all values to be sortable and support adding +1
and the value returned will be the largest value in the enum incremented by 1
  e = auto()
/home/eclips4/programming/programming-languages/cpython/example.py:9: DeprecationWarning: In 3.13 the default `auto()`/`_generate_next_value_` will require all values to be sortable and support adding +1
and the value returned will be the largest value in the enum incremented by 1
  f = auto()
SOME_CLS_B.a
SOME_CLS_B.b
SOME_CLS_B.c
SOME_CLS_B.d
SOME_CLS_B.e
SOME_CLS_B.f

And in 3.13+ it becomes an error:

Traceback (most recent call last):
  File "/home/eclips4/programming/programming-languages/cpython/example.py", line 3, in <module>
    class SOME_CLS_B(Enum):
    ...<5 lines>...
        f = auto()
  File "/home/eclips4/programming/programming-languages/cpython/example.py", line 6, in SOME_CLS_B
    c = auto()
    ^
  File "/nix/store/j73qswfvgslfd055xqz2mh683347649c-python3-3.13.0/lib/python3.13/enum.py", line 431, in __setitem__
    v.value = self._generate_next_value(
              ~~~~~~~~~~~~~~~~~~~~~~~~~^
            key, 1, len(self._member_names), self._last_values[:],
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            )
            ^
  File "/nix/store/j73qswfvgslfd055xqz2mh683347649c-python3-3.13.0/lib/python3.13/enum.py", line 1248, in _generate_next_value_
    raise TypeError('unable to sort non-numeric values') from None
TypeError: unable to sort non-numeric values

So, there's nothing left to fix because it has already been fixed :)

[AvocadoStyle]

Hey @Eclips4, I understand that newer Python versions (like Python 3.13) have added error handling for this scenario. However, my point is that there shouldn't need to be any error handling in this case, and it's actually perfectly acceptable to mix auto() with other types, as it was in Python 3.10.

Example of python3.10 execution of the same "issue":

from enum import Enum, auto

class SOME_CLS_B(Enum):
    a = auto()
    b = "other type than int or auto"
    c = auto()
    d = auto()
    e = auto()
    f = auto()

# Testing outputs
print(SOME_CLS_B.a)  # <SOME_CLS_B.a: 1>
print(SOME_CLS_B.b)  # <SOME_CLS_B.b: 'other type than int or auto'>
print(SOME_CLS_B.c)  # <SOME_CLS_B.c: 2>
print(SOME_CLS_B.d)  # <SOME_CLS_B.d: 3>
print(SOME_CLS_B.e)  # <SOME_CLS_B.e: 4>
print(SOME_CLS_B.f)  # <SOME_CLS_B.f: 5>

As we can see, the auto() function continues to increment the count despite the inclusion of a non-integer type (b in this case). Many developers are mixing the usage of auto() and other types in their Enum classes for various reasons, and it worked well in Python 3.10. I dont see a reason to raise an exception for such a thing.

My point it that it should be fixed, just like it was before in Python 3.10 - rather than raise an Exception to handle that issue.
You said that So, there's nothing left to fix because it has already been fixed :) it's not a fix if something works great, You're using it and it's broken, And than you decide not to use it (raising an exception rather than make it work like before).

[Eclips4]

cc @ethanfurman

[Eclips4]

My point it that it should be fixed, just like it was before in Python 3.10 - rather than raise an Exception to handle that issue.
You said that So, there's nothing left to fix because it has already been fixed :) it's not a fix if something works great, You're using it and it's broken, And than you decide not to use it (raising an exception rather than make it work like before).

Sorry, but it's too late for anything older than 3.14. This deprecation warning has been raised for two years, and now, in 3.13, it raises an exception. You can submit a PR with a fix, and then we will consider it. If this goes well, this change will be implemented in 3.14

[AvocadoStyle]

@Eclips4 Try to consider it right now :) If you think this change (Which is not a change because as we discussed - it was WORKING in Python <=3.10 ) I will try to submit a PR which make the things work just like the things were working before Python <= 3.10 But i need your consideration right now for that effort.

@ethanfurman FYI.

Thanks.

[ethanfurman]

I just tested every version between 3.9 - 3.13. 3.9 - 3.11 give the correct results:

[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import Enum, auto
>>> 
>>> class SOME_CLS_B(Enum):
...     a = auto()
...     b = "other type than int or auto"
...     c = auto()
...     d = auto()
...     e = auto()
...     f = auto()
... 

>>> print(repr(SOME_CLS_B.a))
<SOME_CLS_B.a: 1>

>>> print(repr(SOME_CLS_B.b))
<SOME_CLS_B.b: 'other type than int or auto'>

>>> print(repr(SOME_CLS_B.c))
<SOME_CLS_B.c: 2>

>>> print(repr(SOME_CLS_B.d))
<SOME_CLS_B.d: 3>

>>> print(repr(SOME_CLS_B.e))
<SOME_CLS_B.e: 4>

>>> print(repr(SOME_CLS_B.f))
<SOME_CLS_B.f: 5>

3.12 gives the correct results, along with a warning.

3.13 now raises an exception.

@AvocadoStyle, how did you get the results you are showing?

[AvocadoStyle]

@ethanfurman Seems like i did it as part of the docker execution, The docker installed python with rc version, And thats the reason it happen, For example python 3.11.0rc1 ver and not python3.11 the official release.

But either So i think that we should have the ability to run auto() mixture with other Enum members with other types rather than auto(), I will try to submit a PR for that issue.

@ethanfurman WDYT?

[ethanfurman]

@AvocadoStyle, Does WDYT stand for "what do you think"?

auto() is not actually the problem -- it simply calls _generate_next_value_ to do the work. The 3.13 version of Enum._generate_next_value_ is not going to change.

Note that for your own code base you can make your own base Enum and copy in the 3.11 version of _generate_next_value_ and you'll be good to go:

from enum import Enum

class MyBaseEnum(Enum):
    @staticmethod
    def _generate_next_value_(...):
        # 3.11 code here