The Steering Council discussed this topic at our meeting yesterday. We have some discomfort about the changes to Enum’s str and repr in Python 3.10, both in the specific changes and in the way the changes were decided on. No knock on Ethan or others who participated in those decisions, it’s just that to us, the changes cumulatively feel like they need a more formal, centralized discussion to understand all the issues in detail. While we’re stopping short of requiring it, the Steering Council strongly suggests that for Python 3.10, the changes in Enum’s str and repr be reverted back to the Python 3.9 behavior, and that a PEP be written for Python 3.11. Cheers, -Barry (on behalf of the Steering Council)
On Jun 28, 2021, at 00:56, Ethan Furman <ethan@stoneleaf.us> wrote:
I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str() in 3.10 and another in 3.11 is less than ideal, so this new thread is to collect comments about Enum and it's str() and repr() and whether the changes take effect in 3.10, 3.11, or both.
TL;DR -- sorry, there isn't one.
History: -------- As Enum and IntEnum have started proliferating in the stdlib, some of those enumerations have changed the str() and repr() of their members -- for example, in 3.8 re.RegexFlag had its repr() and str() changed to be module.name (re.ASCII) for both instead of <enum_class.name: value> (<RegexFlag.ASCII: 256>) for the repr(); that change made sense because all the members are exported to re's global name space, and they are accessed as `re.ASCII` in existing code.
While a good change (in my opinion and with which I had nothing to do), we now have stdlib enumerations with differing str() and repr()s, which is a minor ding against recognizability and usability.
Current 3.10 Changes -------------------- In an effort to standardize the stdlib enums, a new decorator was added: global_enum(). It can be called manually (for example in re.RegexFlag), or automatically by Enum._convert_ (for example in ssl.VerifyFlags).
That changed was visually appealing, and I had users wanting that type of output for Enum in general, so after asking for feedback on python-dev and python-ideas (and receiving little) I changed the basic str() and repr() of Enum to:
- str(): NAME - repr(): enum.NAME
While working on some other bugs/changes in Enum.__format__ and serialization in general, I have come to believe that IntEnum (and IntFlag) should be as near-perfect a drop-in replacement as possible for when they are used to replace existing integer constants (which I believe is their most important use-case).
Reverting 3.10 Changes ---------------------- I have been increasingly unhappy with the general `Enum.__repr__` change, so while the stdlib global repr() change is staying, Enum, IntEnum, etc., is going back to <enum_class.NAME: value>.
Proposed 3.10 Change (for 3.10.0 beta 4) ---------------------------------------- In order to improve the drop-in replacement use-case for IntEnum and IntFlag, I would like to change the str() for those two to be simply the value of the member, as if it was still a plain integer and not part of an enumeration. At that point the only obvious difference would be the repr(), which I think is the most important and useful change as that is what (should) show up in log files, the REPL, etc.
This would also make IntEnum and IntFlag consistent with StrEnum as, for other reasons, StrEnum member str()s are the values of the members rather than the names of the members. Note also that this change would not affect user created enumerations that mixed in int on their own.
The Question ------------ With all the changes currently happening to the str()s and repr()s of the various enums, what are the good reasons to not make this final change now, and instead have one more change in 3.11?
-- ~Ethan~
Summary of Enum str()s and repr()s by category
| | repr() | str() | format() | stdlib global | re.ASCII | re.ASCII | 256 | Enum | <Color.RED: 1> | Color.RED | RED | IntEnum | <Color.RED: 1> | 1 | 1 | int, Enum | <Color.RED: 1> | Color.RED | 1 (will be RED in 3.12 due to back-compatibility | | | constraints which should affect very few people as | | | as they are probably using IntEnum instead of mixing | | | in int themselves -- comments about this likelihood also | | | appreciated) _______________________________________________ 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/ZMC67QA2... Code of Conduct: http://python.org/psf/codeofconduct/