PyQt6: QEvent.type() returns int instead of QEvent.Type

Florian Bruhin me at the-compiler.org
Wed Apr 27 17:25:33 BST 2022 

On Wed, Apr 27, 2022 at 03:58:22PM +0100, Phil Thompson wrote:
> 
> On 26/04/2022 20:49, Florian Bruhin wrote:
> > On Tue, Apr 26, 2022 at 09:36:25PM +0200, Florian Bruhin wrote:
> > > On Tue, Apr 26, 2022 at 09:19:05AM +0100, Phil Thompson wrote:
> > > >
> > > > On 21/04/2022 10:37, Florian Bruhin wrote:
> > > > > Hey,
> > > > >
> > > > > With PyQt5:
> > > > >
> > > > >     >>> evtype = QEvent(QEvent.Type.User).type()
> > > > >     >>> evtype
> > > > >     1000
> > > > >     >>> type(evtype)
> > > > >     <class 'PyQt5.QtCore.QEvent.Type'>
> > > > >
> > > > > and even:
> > > > >
> > > > >     >>> evtype = QEvent(QEvent.Type.User + 1).type()
> > > > >     >>> evtype
> > > > >     1001
> > > > >     >>> type(evtype)
> > > > >     <class 'PyQt5.QtCore.QEvent.Type'>
> > > > >
> > > > > but with PyQt6, the type information gets lost:
> > > > >
> > > > >     >>> evtype = QEvent(QEvent.Type.User).type()
> > > > >     >>> evtype
> > > > >     1000
> > > > >     >>> type(evtype)
> > > > >     <class 'int'>
> > > > >
> > > > > From what I understand, it's not possible to convert arbitrary values
> > > > > into an IntEnum:
> > > > >
> > > > >     >>> QEvent.Type(QEvent.Type.User + 1)
> > > > >     [...]
> > > > >     ValueError: 1001 is not a valid QEvent.Type
> > > > >
> > > > > But least for types which are part of QEvent.Type, calling .type()
> > > > > should perhaps return the IntEnum value again instead of falling back to
> > > > > an int without any type information? Given that IntEnum is an int
> > > > > subclass, this should be a backwards-compatible change too.
> > > >
> > > > I've been adopting a piecemeal approach to this sort of thing so far. For
> > > > example having QEvent.type() return an int and adding an extra QEvent ctor
> > > > that accepts an int, and similar with gesture types. However the issue you
> > > > point out in your other email (new enum members in later versions of Qt) is
> > > > something I hadn't considered.
> > > >
> > > > I think the solution is to take the approach you suggest above and apply it
> > > > to all enums (no matter what their base type is). In other words, when
> > > > converting from Python to a C++ enum both a Python enum and an int will be
> > > > accepted. When converting from a C++ enum to Python then the corresponding
> > > > enum member will be returned or an int if there is no such member.
> > > >
> > > > This would mean that there is no need for me to apply special treatment to
> > > > individual methods (as the change is implemented in the sip module) and the
> > > > approach should be future-proof.
> > > >
> > > > Thoughts?
> > > 
> > > Hm, I don't really like the lost type safety when accepting ints.
> > > However, at the same time I can't think of a proper way to solve the
> > > "new enum members" problem.
> > > 
> > > I tried coercing Python into having some kind of special
> > > SomeEnum.missing(42) value instead, which acts like a member of the
> > > enum, but can also hold an arbitrary value. enum.py sure is some crazy
> > > black magic. I bet it would be possible somehow (custom enum metaclass
> > > defining __instancecheck__ perhaps?), but at this point there is so
> > > much
> > > black magic involved I'm not sure it would be a better solution.
> > 
> > I spoke too soon, here is something that seems to work, somehow.
> > The point about "probably too much black magic" still stands, though.
> 
> Nice. The obvious problem is the knowledge of the enum internals.

Right. The code still works properly when removing the setting of
_value2member_map_, though. I was copying this from a similar suggestion
using _missing_ initially: https://stackoverflow.com/a/57179436

There, it's only needed so that calling CustomEnum(3) later returns the
same object again. I believe this isn't needed in PyQt's case, and
actually it doesn't work properly either (since we're not using
_missing_).

Is it strange that the user gets an enum value back, for which the
invariant   SomePyQtEnum(member.value) == member   does not hold true?

I don't believe it really is, given that the PyQt enum really doesn't
know what member the value corresponds to after all.

One thing that might require some extra care is making the values
pickleable I suppose:

    >>> pickle.loads(pickle.dumps(SomePyQtEnum._from_qt(3)))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.10/enum.py", line 385, in __call__
        return cls.__new__(cls, value)
      File "/usr/lib/python3.10/enum.py", line 710, in __new__
        raise ve_exc
    ValueError: 3 is not a valid SomePyQtEnum

I know nothing about pickle, but if you're still interested in this
approach, I can try to make it work too.

> I'm still favouring the int approach. I can't think of a case that code
> would start to break when a newer version of Qt was used with an older PyQt
> (which is the main problem).

My main gripe with that approach is that it allows it to pass ints
instead of enum members again (even corresponding to a different enum,
of course).

If you'd prefer not messing with the enums directly, I'd prefer an
approach which at least tries to be type-safe to some degree, e.g. via a
sip.UnknownEnumMember(QEvent.Type, 1001) or somesuch.

That way:

- ints can't be accidentally passed where enum members are expected
- Passing a sip.UnknownEnumMember belonging to a different enum would
  still raise a TypeError of some sorts.
- In summary, whatever I get out of PyQt I can only pass into PyQt at
  the correct place again, which seems like a great thing.
- Type checkers could probably made to understand it statically
  (I think?).
- From the __repr__, it would still be clear what kind of thing I'm
  dealing with, rather than just seeing 1001 and having no idea where it
  comes from.

Florian

-- 
            me at the-compiler.org | https://www.qutebrowser.org 
       https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
       GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
             I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20220427/946b5533/attachment.sig>

More information about the PyQt mailing list