Oh, it's definitely too late for 3.10. On Wed, Jun 23, 2021 at 8:16 PM Jelle Zijlstra <jelle.zijls...@gmail.com> wrote:
> > > 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/ > -- --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-change-the-world/>
_______________________________________________ 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/WXRTAWKIMSGX7GNIK3XCWU7BGB3QXRVL/ Code of Conduct: http://python.org/psf/codeofconduct/
