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~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/FJ3KXKXSYHPZZI7A25LEH4IANXECRIN4/
Code of Conduct: http://python.org/psf/codeofconduct/
