TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be
`int.__str__`
IntEnum and IntFlag are becoming more common in the stdlib. They currently
show up in
* http
* re
* signal
* ssl
* socket
to name just a few.
3.10 already has some changes to the str() and repr() of enums in general:
HTTPStatus -> OK and HTTPStatus.OK instead of HTTPStatus.OK and
<HTTPStatus.OK: 200>
Enum's that are taking the place of global constants have the repr() further
modified:
RegexFlag -> ASCII and re.ASCII instead of RegexFlag.ASCII and
<RegexFlag.ASCII: 256>
When Enum was first created we also modified the default JSON encoder to be able to encode int- and float-based
enumerations; however, with the continued rise of Python in the world a user stumbled upon a stdlib encoder that we
missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]).
IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could be drop-in replacements for existing integer
constants. At the time I didn't fully appreciate how those constants were used in code with regards to str() -- which
is to say, changing the str() output can be a breaking change, even inside the stdlib.
What I would like to do for the enum module is make any supplied mixed-in enums
a little more vanilla:
* str() is the mixed-in `__str__`, not the Enum `__str__`
* format() is the mixed-in `__format__`, not the Enum `__format__` (this is the
current effective behavior already)
Other benefits, particularly repr(), would remain. Note that a mixed enum created by a user would have the normal Enum
`__str__` and `__format__`.
Summary: mixed enums provided in the enum module should maintain the mixed
data types `__str__` and `__format__`.
Thoughts?
--
~Ethan~
[1] https://bugs.python.org/issue33025
_______________________________________________
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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
Code of Conduct: http://python.org/psf/codeofconduct/
