Mismatch with QtGui.QPalette.ColorRole members between run-time and type stubs

[AWhetter]

When using PySide6 or PyQt6, QtGui.QPalette.Foreground does not exist. This is because Foreground was removed in Qt6.
However the type stubs say that it does exist, because they're based on the PySide2 interface.

I'm unsure how to address this in Qt.py. If I'm understanding Qt.py correctly, it doesn't currently patch any objects from the underlying binding, it creates its own module and patches onto those. When patching objects, the patches are supposed to get applied to a newly created object in QtCompat.

So if we were to add QtGui.QPalette to QtCompat with a Foreground attribute, then then there's a mismatch between what's allowed when using PySide2 and PySide6.
With PySide2, Qt.QtGui.QPalette.Foreground exists. With PySide6, the type stubs say Qt.QtGui.QPalette.Foreground but it only exists as Qt.QtCompat.QPalette.Foreground.
If we removed Qt.QtGui.QPalette.Foreground from the type stubs then they wouldn't represent a complete PySide2 interface.

Perhaps it makes more sense to remove the members from QtGui.QPalette in the type stubs, to encourage accessing the members from QtGui.QPalette.ColorRole instead, in which case this would be an issue for types-pyside2 to address.

[MHendricks]

Having started converting our code to PyQt6 which is even more progressive(seemingly removed all Qt5 deprecated features) than PySide6 I agree that anything deprecated in PySide2 should be avoided by any code that may get ported to Qt6. However that may affect the support for Qt4 if anyone actually still needs that. When we actually drop Qt4/py2 support Qt.py should be based on PySide6.

I think the best we could do is remove the deprecated items from the type stubs to encourage the use of the new members. However as you say it seems that is a issue for types-pyside2 to address.

I don't think we should add the enums to QtCompat due do to the shear number of them and they are stored across different modules and individual classes. The compatibility classes created on QtCompat are providing unified function implementations when the python bindings are different.

The rest of this post is going into too much detail over a bit of the underlying way Qt.py is implemented if interested.

Qt.py creates replacement modules for QtCore, QtGui, etc. But it doesn't create replacement classes for the individual classes contained inside those modules.

>>> import Qt, PyQt6
>>> print(Qt.QtCore is PyQt6.QtCore, Qt.QtCore, PyQt6.QtCore)
False <module 'Qt.QtCore'> <module 'PyQt6.QtCore' from 'C:\\blur\\venvs\\qt6\\Lib\\site-packages\\PyQt6\\QtCore.pyd'>
>>> print(Qt.QtCore.QObject is PyQt6.QtCore.QObject, Qt.QtCore.QObject, PyQt6.QtCore.QObject)
True <class 'PyQt6.QtCore.QObject'> <class 'PyQt6.QtCore.QObject'>

See how the Qt.QtCore module is different than the underlying PyQt6.QtCore module, but the QObject class exposed by Qt is the exact same class object as in PyQt6(this applies to all bindings).

This means that Qt.py can not change anything about QObject or the other objects exposed on QtCore, QtWidgets, etc. This is why we several compatibility classes have been added to QtCompat like Qt.QtCompat.QHeaderView