On 4/20/21 8:46 AM, Guido van Rossum wrote:
I'd guess it is totally up to the object, since str() calls `__str__` and format() calls `__format__`. Of course this now begs the question whether those enums should perhaps change their `__format__` to match their `__str__`...?
When Enum was designed we made sure and captured `__repr__` and `__str__`, but not `__format__`. So at this point, `__format__` is the mixed-in data type's -- so `int.__format__` in the case of IntEnum. However, if a user updates the `__str__` of their Enum, then that will be used in the format: ```python from enum import IntEnum class Color(IntEnum): RED = 1 format(Color.RED) # '1' class Color(IntEnum): RED = 1 def __str__(self): return 'one' format(Color.RED) # 'one' ```
But that would not suit your purpose. Then again, how would one get the pretty IntEnum-specific representation in a format- or f-string? I guess f"{flag!s}" would work.
Yup, that does work. There is at least one user who is depending on `format()` using `int.__format__` because they filed a bug report when I broke it. Moving forward, I'm not sure having format() and str() ever be different is a good idea, especially since users who need, for example, Color.RED to be '1' can simply add a `__str__ = int.__str__` to their own custom base IntEnum class and be good to go. If we deprecate the current behavior now we could change it in 3.12. Thoughts? -- ~Ethan~