You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Python 3.11.0b4 str(enum) giving integer value and not name #94763
changed the title [-]Python 3.11 str(enum) giving integer value and not name[/-][+]Python 3.11.0b4 str(enum) giving integer value and not name[/+]on Jul 11, 2022
#22392 does seem somewhat related but it does mention only string enums should use the values and other types use the member name. If this is a change made on purpose that's fine, I just want to know for sure and whether to update my tests.
This is (now) the expected behavior for any mixed Enum/Flag defined in the enum module. The expectation is that existing code being replaced with IntEnum, StrEnum, or IntFlag should have its str() continue to be the same as it was; if you mix your own (i.e. MyIntEnum(int, Enum)) then you get the original behavior of both repr() and str() being overridden. In either case, format() will be the same as str().
@ethanfurman I know this is probably water under the bridge now, but I wonder why breaking changes like this are not called out more distinctly in the What's New (e.g. by including the word "breaking")?!
We just had code using plain IntEnum/IntFlag change behaviour on Python 3.11, and now have a hard time working around that breaking change (probably by inheriting from (int, Enum) to support all current Python versions and our user's use case.
Hitting surprises like this is unpleasant, and I have to admit they somewhat undermine my trust in the versioning scheme.
Could breaking changes at least be marked/called out with "breaking" or somesuch? Then it's easier to grep the What's new when, against expectations, a minor version upgrades changes public behaviour. :-(
Reacted by jamiecha, Fabian Henze and Nico Neumann
Activity
[-]Python 3.11 str(enum) giving integer value and not name[/-][+]Python 3.11.0b4 str(enum) giving integer value and not name[/+]AlexWaygood commentedon Jul 11, 2022
I believe that this is a deliberate behaviour change from previous versions. The Steering Council specifically approved this change; see the penultimate paragraph here regarding aligning
str()andformat()forIntEnum: https://mail.python.org/archives/list/python-dev@python.org/message/RN3WCRZSTQR55DOHJTZ2KIO6CZPJPCU7/jborean93 commentedon Jul 11, 2022
#22392 does seem somewhat related but it does mention only string enums should use the values and other types use the member name. If this is a change made on purpose that's fine, I just want to know for sure and whether to update my tests.
Edit: Sorry you posted just as I was commenting.
ethanfurman commentedon Jul 14, 2022
My apologies for the confusion, I need to get the Whats New updated with the Enum changes/additions.
jborean93 commentedon Jul 14, 2022
No worries, so just to confirm this is expected for pretty much any enum types and not just a string enum as mentioned in the linked issue?
ethanfurman commentedon Jul 15, 2022
This is (now) the expected behavior for any mixed Enum/Flag defined in the enum module. The expectation is that existing code being replaced with
IntEnum,StrEnum, orIntFlagshould have itsstr()continue to be the same as it was; if you mix your own (i.e.MyIntEnum(int, Enum)) then you get the original behavior of bothrepr()andstr()being overridden. In either case,format()will be the same asstr().pitrou commentedon Oct 26, 2022
@ethanfurman So what is the idiomatic way to get the member name rather than the value? In 3.10 I have:
How do I get
'FileType.Directory'with 3.11?johnthagen commentedon Oct 29, 2022
I know it was intentional, but just as a data point, the breaking changes to
formatforMyEnum(str, Enum)did cause some downstream breakage, such as:ethanfurman commentedon Nov 14, 2022
@pitrou Either change the
__str__for theFileTypeenum, or make a new base enum to inherit from:refactor: SEP-0011, removed comments on SetOptions.clearFlags and Set…
bilderbuchi commentedon Jul 21, 2023
@ethanfurman I know this is probably water under the bridge now, but I wonder why breaking changes like this are not called out more distinctly in the What's New (e.g. by including the word "breaking")?!
We just had code using plain
IntEnum/IntFlagchange behaviour on Python 3.11, and now have a hard time working around that breaking change (probably by inheriting from (int, Enum) to support all current Python versions and our user's use case.Hitting surprises like this is unpleasant, and I have to admit they somewhat undermine my trust in the versioning scheme.
Could breaking changes at least be marked/called out with "breaking" or somesuch? Then it's easier to grep the What's new when, against expectations, a minor version upgrades changes public behaviour. :-(
refactor: SEP-0011, removed comments on SetOptions.clearFlags and Set…
refactor: SEP-0011, removed comments on SetOptions.clearFlags and Set…