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
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?
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.
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.
Activity
The-Compiler commentedon May 26, 2022
For some context: Python 3.11 and mixing of enum.IntFlag.
Reproducer:
but
Relevant commit: 7aaeb2a ("bpo-38250: [Enum] single-bit flags are canonical (GH-24215)").
ethanfurman commentedon May 26, 2022
Are you concerned that the repr() has changed, or that the result is no longer of type
flag?philthompson10 commentedon May 26, 2022
The change in type is the problem.
ethanfurman commentedon May 26, 2022
Changing the default to
KEEPmake sense.Out of curiosity, and ignoring backwards compatibility, do you think the default for an IntFlag should be
KEEPorEJECT?philthompson10 commentedon May 27, 2022
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.
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…
ethanfurman commentedon 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.Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11
Patch PyQt6 QUrl flag behavior for Python 3.11