[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

Oh, it's definitely too late for 3.10. On Wed, Jun 23, 2021 at 8:16 PM Jelle Zijlstra wrote:

El mié, 23 jun 2021 a las 19:54, Ethan Furman () escribió:

...

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

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

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?

This seems like it's going to be a backwards incompatible change that may turn out to be fairly disruptive for the codebase I have to maintain. We use IntEnum heavily and any change in behavior is likely to require migration work. I'm already pretty worried about the other enum changes in 3.10.

...

-- ~Ethan~

[1] https://bugs.python.org/issue33025 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/HE36QRXP... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/ZIUN5MTA... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...