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 . It's not too bad, though; about
half a dozen failing tests out of ~5000, and they're probably not terribly
hard to fix.
Still, changes like this add up and make it harder to upgrade Python
seamlessly, so we should still try to minimize them.
El mié, 23 jun 2021 a las 20:13, Jelle Zijlstra ()
escribió:
>
>
> 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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/6JVFXFPFWKKOBKZTQ3HQO7XFRQC4IYSP/
Code of Conduct: http://python.org/psf/codeofconduct/
