https://bugzilla.redhat.com/show_bug.cgi?id=1970626
--- Comment #2 from Miro Hrončok <mhroncok(a)redhat.com> ---
This is the minimal failing example extracted from
/usr/share/ibus-typing-booster/engine/itb_util.py:
from enum import Flag
from gi.repository import Gtk
class InputHints(Flag):
def __new__(cls, attr: str):
obj = object.__new__(cls)
if hasattr(Gtk, 'InputHints') and hasattr(Gtk.InputHints, attr):
obj._value_ = getattr(Gtk.InputHints, attr)
print(f'{obj._value_=}')
else:
obj._value_ = 0
return obj
SPELLCHECK = ('SPELLCHECK')
The output is:
$ python3 reproducer.py
...
obj._value_=<flags GTK_INPUT_HINT_SPELLCHECK of type Gtk.InputHints>
/usr/lib64/python3.10/enum.py:73: Warning: unsupported arithmetic operation for
flags type
num &= num - 1
Traceback (most recent call last):
File "//reproducer.py", line 20, in <module>
class InputHints(Flag):
File "/usr/lib64/python3.10/enum.py", line 484, in __new__
raise exc
File "/usr/lib64/python3.10/enum.py", line 246, in __set_name__
and _is_single_bit(value)
File "/usr/lib64/python3.10/enum.py", line 73, in _is_single_bit
num &= num - 1
TypeError: unsupported operand type(s) for &=: 'InputHints' and
'NoneType'
Setting obj._value_ = 0 does not produce the traceback.
Actually setting obj._value_ to any number does not produce the traceback.
My guess is that with the enum.Flag implementation overhaul, some internals
have changed. I don't think messing with obj._value_ in __new__ is a supported
thing to do, so I won't consider this a Python bug per se -- obj._value_ is
supposed to be a numeric value, not another Flag member.
Replacing:
obj._value_ = getattr(Gtk.InputHints, attr)
With:
obj._value_ = int(getattr(Gtk.InputHints, attr))
In both InputHints and InputPurpose seems to get the job done.
--
You are receiving this mail because:
You are on the CC list for the bug.