IntEnum, IntFlag, and the stdlib
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
El mié, 23 jun 2021 a las 19:54, Ethan Furman (
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/
Oh, it's definitely too late for 3.10.
On Wed, Jun 23, 2021 at 8:16 PM Jelle Zijlstra
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...
Ethan reached out to me for clarification and it turns out the work for
updating to the 3.10 changes actually isn't too bad for our codebase. On a
quick test, I did see several failures as a result of the change to str()
and repr() for enum members. For example, the repr() of a compound data
structure changed because it incorporated the str() of an enum somewhere
inside the data structure. Similarly, another test relied on the repr() of
an enum member being of the form
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/
On Thu, 24 Jun 2021, 12:58 pm Ethan Furman,
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
That's already a major loss in enum repr() usability - the whole point of having both forms in the output was so that repr() gave you both the symbolic name and the raw number, allowing them to be looked up in external systems without needing access to the original enum definition to translate between forms. For the other proposal, I think you're stuck from a backwards compatibility point of view - the default needs to be the current behaviour, with some way to opt out of using the symbolic str representation. Cheers, Nick.
On Mon, 28 Jun 2021, 12:44 am Nick Coghlan,
For the other proposal, I think you're stuck from a backwards compatibility point of view - the default needs to be the current behaviour, with some way to opt out of using the symbolic str representation.
Although, looking at that problem from a different perspective: the contracts on "str()" and "repr()" under subclassing are *super* weak, since they're primarily designed for consumption by humans. If consuming code accepts subclasses, but requires them to behave *identically* to the base class, it should either be coercing them to the base class first, or using the better defined string formatting options. Cheers, Nick.
Cheers, Nick.
participants (4)
-
Ethan Furman
-
Guido van Rossum
-
Jelle Zijlstra
-
Nick Coghlan