El mié, 23 jun 2021 a las 19:54, Ethan Furman (<et...@stoneleaf.us>) 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 > <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? > 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-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/ >
_______________________________________________ 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/ZIUN5MTAS75QI2UFSIN5YO6SVIY3AXNY/ Code of Conduct: http://python.org/psf/codeofconduct/
