Default enum.FlagBoundary should be KEEP? · Issue #93250 · python/cpython · GitHub

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?

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 KEEP make sense.

Out of curiosity, and ignoring backwards compatibility, do you think the default for an IntFlag should be KEEP or EJECT?

I don't feel comfortable with the type being different depending on the values provided, so I don't like EJECT as 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. KEEP solves this problem. I have the same problem with Enum and IntEnum and have effectively implemented KEEP for 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.

gh-93250: [Enum] Change IntEnum boundary to KEEP for backwards compat…

pythongh-93250: [Enum] Change IntEnum boundary to KEEP for backwards …

gh-93250: [Enum] Change IntEnum boundary to KEEP for backwards compat…

KEEP restored 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.

Patch PyQt6 QUrl flag behavior for Python 3.11

Default enum.FlagBoundary should be KEEP? · Issue #93250 · python/cpython · GitHub

Default enum.FlagBoundary should be KEEP? #93250

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Default enum.FlagBoundary should be KEEP? · Issue #93250 · python/cpython · GitHub

Default enum.FlagBoundary should be KEEP? #93250

Description

Activity

The-Compiler commented on May 26, 2022

ethanfurman commented on May 26, 2022

philthompson10 commented on May 26, 2022

ethanfurman commented on May 26, 2022

philthompson10 commented on May 27, 2022

ethanfurman commented on May 27, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions