Repository navigation
Default enum.FlagBoundary should be KEEP? #93250
Description
Activity
For some context: Python 3.11 and mixing of enum.IntFlag.
Reproducer:
import enum A = enum.IntFlag("A", {"x": 1}) B = enum.IntFlag("B", {"y": 2}) val = A.x | B.y print(val, type(val))
$ python3.10 -c 'import enum; A = enum.IntFlag("A", {"x": 1}); B = enum.IntFlag("B", {"y": 2}); val = A.x | B.y; print(val, type(val))' A.B.y|x <enum 'A'>but
$ python3.11 -c '...' 3 <class 'int'>Relevant commit: 7aaeb2a ("bpo-38250: [Enum] single-bit flags are canonical (GH-24215)").
Are you concerned that the repr() has changed, or that the result is no longer of type
flag?The change in type is the problem.
Changing the default to
KEEPmake sense.Out of curiosity, and ignoring backwards compatibility, do you think the default for an IntFlag should be
KEEPorEJECT?I don't feel comfortable with the type being different depending on the values provided, so I don't like
EJECTas a default as the behaviour might be too surprising.My use case is atypical. I am wrapping the enums of a C++ library and can't guarantee that the wrappers know about all the possible values that the library might provide.
KEEPsolves this problem. I have the same problem withEnumandIntEnumand have effectively implementedKEEPfor those by providing them with an appropriate implementation of_missing_.Note that my original concern was about the lack of the usual deprecation cycle for a change in behaviour rather than the change itself.
- added a commit that references this issue
on May 27, 2022 - added a commit that references this issue
on May 27, 2022 KEEPrestored as the default, and likely to stay that way -- an early design decision was to persist the flag type for bit-wise operations. The exact flag type and behavior will depend on the left-most operand.Reacted by Freya Bruhin- added a commit that references this issue
on May 30, 2022 - added 5 commits that reference this issue
on Jun 17, 2022
The FlagBoundary added to enums in Python v3.11 has defaults that break compatibility with previous versions. Shouldn't the default initially be KEEP, with a deprecation warning that it will be changed in a future version?