Since this is a bugfix to an existing change in 2.3.1, it seems like it would be nice to get this in that release also before the previous change ships, to avoid any discruption.

Unfortunately, I couldn't think of good tests for QNativeGestureEvent, QEnterEvent, QTabletEvent, QHoverEvent, and QWheelEvent, which all are the child classes of QSinglePointEvent in Qt6. I'd really appreciate some help here.

Maybe can be omitted for now, or just check that they have the expected type and are subclasses of isinstance, and/or the correct attributes? It doesn't have to be fancy, and our tests currently aren't really that sophisticated generally—you've already gone above and beyond in a lot of cases :)

Added dummy checks (assert something is not None).

As a side note, would qtbot.waitExposed help the stalls of the tests on macOS CI with Python 3.7? The docs read

This is mainly useful for asynchronous systems like X11, where a window will be mapped to screen some time after being asked to show itself on the screen.

I'd like to try, but not in a PR here.

One comment on how to simplify the tests

That actually is what the review process for. Thanks, @CAM-Gerlach!

One of the tests failed, but it's not me this time. I wish there was a way to stabilize the test environment and reuse it to speed the tests up.

I restarted the failed job. If it keeps happening, I can look into it further or explore other options like locked dependencies or additional caching.

Thanks, @ccordoba12! What line length do you prefer? I stick to 120 char limit. I'll gladly follow your code style to save you the extra work on cosmetics.

@CAM-Gerlach, please apply such formatting changes without consulting me to save time (especially when a commit delays a release). Living in Europe, I read the comments many hours after they appear.

Thanks, @ccordoba12! What line length do you prefer? I stick to 120 char limit. I'll gladly follow your code style to save you the extra work on cosmetics.

At least in most Spyder projects, nominally 79 characters per PEP 8, but the current code is somewhat inconsistent until we blacken it (and even then, we might want to go with the default 88 characters to avoid too much churn and to avoid too many line breaks on the large number of complex lines QtPy has). I've tried to avoid too many style nitpicks myself except when in the course of another suggestion.

@CAM-Gerlach, please apply such formatting changes without consulting me to save time (especially when a commit delays a release). Living in Europe, I read the comments many hours after they appear.

Sure, I can do that for you in the future if you like; we just generally like to be very respectful of the author's wishes and not do so without their explicit permission (which you've now given) to avoid any friction and misunderstandings (as has happened in the past). Thanks!