Combining int and Enum, as with enum.IntEnum results in a class where __str__ cannot be effectively overridden. For example:

from enum import IntEnum

class myIntEnum(IntEnum):
    x = 1
    
    def __str__(self):
        return 'aaaaAAAa'
    
f'{myIntEnum.x}, {str(myIntEnum.x)}'

Expected output:
'aaaaAAAa, aaaaAAAa'

Actual output:
'1, aaaaAAAa'

Overriding __str__ in this way works as expected if the inherited classes are int or Enum individually. However, it does not work when inheriting (int, Enum) or when inheriting (intEnum).

Presumably this is a side effect of Enum's mixin behavior documented at https://docs.python.org/3/library/enum.html#others and it is possibly related to https://bugs.python.org/issue18264 .

I mistyped - __str__ can be overridden effectively, but __format__ has to be overridden instead or overridden also to get the desired f-string behavior.

related cPython code:

If we're in a mixed-in class but the class has overridden __str__(), we should probably use str(self) instead of self._value_.

Note that this isn't really related to f-strings, except that they use the __format__ protocol, as does str.__format__.

>>> format(myIntEnum.x)
'1'

New changeset 2f19e82 by Ethan Furman (thatneat) in branch 'master':
bpo-37479: on Enum subclasses with mixins, __format__ uses overridden __str__ (GH-14545)
2f19e82

New changeset 38c8d39 by Ethan Furman in branch '3.8':
[3.8] bpo-37479: Enum - use correct __format__ (GH-14545)
38c8d39

Thank you, Jason!

Was this change really intended?

The change will make projects break in their behavior when changed from 3.7 to a newer version.

from enum import IntEnum

class Test(IntEnum):
     A = 0
     B = 0

t = Test.A
print(f"0x{t:X} {str(t)}")

is valid python code and also compatible with python 3.7.
But!!!

from enum import IntEnum

class Test(IntEnum):
     A = 0
     B = 0
    
     def __str__(self):
             return self.name.lower()

t = Test.A
print(f"0x{t:X} {str(t)}")

is valid in python 3.7 but due to the change not valid in python 3.8+ anymore.
Since "str" can't be represented by "{:X}".
Since isinstance(t, int) is true in both scenarios, it is to be expected that f"0x{t:X}" will hold. it is an "int" and not a "str"

The str function exists in both cases, the override of the second case shall not alter the behavior of the class !

@zinnjonas This has been corrected in 3.11.