Best Practice for PyQt for incremental migration from Python 2.7 to 3.x

Question

I am in the process of updating code for Py2/Py3 compatibility. Some of the original Python 2.7 code uses PyQt4. The standard Python 3.7 installation which we will be implementing incrementally on our users' systems is not compatible with PyQt4.

In my research, I have found a host of various involved and often convoluted methods of making Python 2.7 play nicely with PyQt5, but this is an untenable solution as the whole reason for the cross-compatibility update is so that:

• users whose systems have not been updated can continue to use the updated modules/packages
• developers will only have to maintain a single version, not a Py2 version and a Py3 version

I have not found much at all that helps with making Python 3.7 talk to PyQt4, so the backwards compatible solution, though preferable, does not seem tenable, either, unless I am (hopefully) mistaken.

Another alternative is to modify the code to check Python versions and do the imports accordingly with if/else or try/except statements.

I would like to know what the best and simplest method is for cross-compatible coding for PyQt4/5 so that the users (most of whom are NOT developers) will have little to no difficulty updating and will NOT need to make changes to their systems to continue to use updated programs before their systems are updated for them.

Answer 1

While [Py]Qt4 is obsolete, I know that, in somehow large or specific environments, system updates cannot be possible or easily done in the near future. I'd suggest you to use Qt.py, which is a "shim" that makes possible to use (almost) transparently all Qt bindings (PySide 1/2 and PyQt 4/5) for both Python 2 and 3.

The overall benefit is pretty simple: you will be able to use PyQt5-ready code, while keeping it usable on older systems that still have to rely on PyQt4.

The most important work you'll need to do is to change all QWidget subclasses as part of QtWidgets module instead of QtGui, and remember that Qt.py automatically attempts to use sip API v2 (which makes all toPyObject conversions unnecessary and much more transparent).
Keep in mind that some classes require manual import from the current binding and obviously there are some differencies in behavior, but besides that, it will make the whole migration much more easier.