IntFlag crashes with no single bit members #93035
Comments
|
83d544b introduced the error when creating the enum but the underlying issue is that multi-bit flags aren't included when iterating the enum. eea8148 Introduced support for multi-bit members but they weren't listed with the enum. On 3.10 this was fixed in 9bf7c2d and remained fixed in 2a9ab75. But it was never fixed in 3.11 and above. sam@samtop ~/Documents/git/cpython (git)-[v3.11.0a5~234] % ./python
Python 3.11.0a4+ (tags/v3.11.0a4-30-g83d544b929:83d544b929, May 21 2022, 09:41:53) [GCC 12.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import IntFlag
>>> class E(IntFlag):
... x = 3
...
>>> list(E)
[]
>>> Python 3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import IntFlag
>>> class E(IntFlag):
... x = 3
...
>>> list(E)
[<E.x: 3>]
>>> The problem might be around here Lines 713 to 727 in b96e20c I will try looking more into it later and I think an extra test should be added for this. |
|
Actually, @ethanfurman, which is (or should be?) the correct behaviour when listing IntFlag enums with multi-bit members? This is what happens on Python 3.10.4 sam@samtop ~ % python
Python 3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import IntFlag
>>> class E(IntFlag):
... x = 1
... y = 3
...
>>> list(E)
[<E.x: 1>, <E.y: 3>]
>>> And on trunk sam@samtop ~/Documents/git/cpython (git)-[main] % ./python
Python 3.12.0a0 (heads/main:fa2b8b75eb, May 21 2022, 10:35:37) [GCC 12.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import IntFlag
>>> class E(IntFlag):
... x = 1
... y = 3
...
>>> list(E)
[<E.x: 1>] |
|
The iteration behavior in trunk is correct. |
|
@ethanfurman How should the following work? (should it work?) def test_bizarre(self):
class Bizarre(Flag):
b = 3
c = 4
d = 6
self.assertEqual(repr(Bizarre(7)), '<Bizarre.d|c|b: 7>')My current patch produces the following >>> repr(Bizarre(7))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/sam/Documents/git/cpython/Lib/enum.py", line 396, in __call__
return cls.__new__(cls, value)
File "/home/sam/Documents/git/cpython/Lib/enum.py", line 729, in __new__
raise exc
File "/home/sam/Documents/git/cpython/Lib/enum.py", line 711, in __new__
result = cls._missing_(value)
File "/home/sam/Documents/git/cpython/Lib/enum.py", line 857, in _missing_
possible_member = cls._create_pseudo_member_(value)
File "/home/sam/Documents/git/cpython/Lib/enum.py", line 872, in _create_pseudo_member_
raise ValueError("%r is not a valid %s" % (value, cls.__qualname__))
ValueError: 7 is not a valid BizarreBehaviour with single-bit members is correct >>> class Bizarre(Flag):
... x = 1
... y = 2
... z = 4
...
>>> Bizarre(7)
<Bizarre.z|y|x: 7>
>>> |
|
If erroring is correct, then I think the error message may need to be amended |
`EnumType` attempts to create a custom docstring for each enum/flag, but that was failing with pathological flags that had no members (only multi-bit aliases).
…ythonGH-93076) `EnumType` attempts to create a custom docstring for each enum/flag, but that was failing with pathological flags that had no members (only multi-bit aliases). (cherry picked from commit 08cfc3d) Co-authored-by: Tobin Yehle <tobinyehle@gmail.com>
Bug report
IntFlagcauses a crash on 3.11.0b1 when there are no single bit members.Minimal example is
this results in
This is used in practice when values with only single bits set aren't valid, eg:
Your environment
The text was updated successfully, but these errors were encountered: