Miro, should this block some python 3.10 tracker?

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.

Upstream PR: https://github.com/mike-fabian/ibus-typing-booster/pull/168

Mike, could you please have a look at the proposed Pull Request and backport it to rawhide if possible? Thanks

Looking ...

python3-enchant seems broken in rawhide:

https://bugzilla.redhat.com/show_bug.cgi?id=1974452

(I noticed this because a test case for Czech failed  when I wanted to fix this bug for ibus-typing-booster in rawhide)

FEDORA-2021-52fe390975 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-52fe390975

FEDORA-2021-52fe390975 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-48e5f2056e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-48e5f2056e

FEDORA-2021-468626eba4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-468626eba4

Included in https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.11.5

FEDORA-2021-48e5f2056e has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-48e5f2056e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-48e5f2056e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-468626eba4 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-468626eba4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-468626eba4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-48e5f2056e has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-468626eba4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.