Dropping support for PyQt4; preparing support for PyQt6. #16836
Comments
|
PyQt4 seems to be in many distros: https://repology.org/project/python:pyqt4/versions but of course, that doesn't really say what their future plans are. |
|
Looks like Debian is in the process of removing Qt4 as well (https://wiki.debian.org/Qt4Removal) and I guess this means Ubuntu will follow suit soon. I don't know what Fedora's plans are, but you may be more aware of them than me? ;) Looking at the repology list, the only remaining "major" (as listed in https://en.wikipedia.org/wiki/Linux_distribution#Widely_used_distributions, which I guess is fairly generous...) distros with PyQt4 packaged (other than those above) are Mageia7 and Slackware (CentOS7, Scientific Linux 7, PCLinuxOS, and OpenSUSE 15 also have it, but they're limited to Py3.6 so already not compatible with the next Matplotlib release). |
|
Qt 4 reached end-of-life on 2015-12-19. Its Python bindings are also EOL: PyQt4 since 2018-08-31 and PySide since 2015-10-14. We deprecated PyQt4 and PySide in Pillow 6.0.0 (April 2019) and removed them in 7.0.0 (January 2020) and have had no issues reported about PyQt4 since before the deprecation. https://pillow.readthedocs.io/en/stable/deprecations.html#pyqt4-and-pyside |
|
I think there are not any plans to drop Qt4 in Fedora, mainly because of one maintainer keen to keep older KDE around. Since it's deprecated upstream, I would guess that PyQt4 will stick around until it fails to build with Python 3. |
|
We require pillow >= 6.2 on master branch so does that mean we have already effectively already dropped support for pyqt4? |
|
You could still use pillow<7 with pyqt4 (but get a deprecation warning). |
|
🐑 sorry, miss understood. |
|
We also don't rely on Pillow's Qt integration (which is not enough for us anyways) so in theory we could still work with Pillow 7 and PyQt4. |
|
Apologies if my comment caused confusion, it was intended as a data point for another library dropping support for PyQt4 and receiving no negative feedback about it. I agree with deprecating PyQt4 in Matplotlib 3.3, it's been EOL for years. The idea of NEP 29, is to reduce community burden by only supporting a subset of non-EOL CPython and NumPy. In a similar spirit, dropping EOL PyQt4 would reduce the maintenance burden of Matplotlib and potentially other community projects. |
|
Support for Qt4 was deprecated in #16836, so the only thing left here is to decide how to support Qt6, or can we close? |
|
we can close this for now and revisit when pyqt6 is out. |
|
Hello Guyz. QtCore.QObject.connect(self.radioButton_UserDefinedCoordinate, QtCore.SIGNAL(_fromUtf8("toggled(bool)")), self.label_5.setEnabled) |
|
@jiten597 This the Matplotlib issue tracker, not a Qt help forum. We can’t help you. |
PyQt4 is getting increasingly difficult to test (I wrote this issue following #16834). AFAICT,
Matplotlib 3.3 will likely not be released before mid-2020(?) which means that it will require Python 3.7+ -- Python 3.6.0 was released in December 2016 (https://docs.python.org/3.6/whatsnew/3.6.html). This means that in practice, the only setup which Matplotlib 3.3 and and PyQt4 can even coexist at all is Windows + Py3.7 + Christopher Gohlke's wheel.
I therefore propose to deprecate the qt4{agg,cairo} backends in Matplotlib 3.3. (From now on I'll just write qtXagg but everything applies just as well to qtXcairo.)
Qt6 is planned for the end of 2020 (https://www.qt.io/blog/2019/08/07/technical-vision-qt-6) and PyQt6 should follow soon after (http://python.6.x6.nabble.com/Wondering-about-PyQt6-td5249539.html). However, instead of introducing a new qt6agg backend, I propose to name the new backend qtagg instead -- with the idea to soft-deprecate qt5agg (this can stay for very long, until qt5 itself dies off just like qt4 did), with the idea that selecting qtagg will just select a qt version based on what's available and on QT_API. This will avoid the currently slightly confused fallback system where we sometimes fallback from qt4 to qt5 or vice-versa depending on what's available, so the version numbers are not really compulsory anyways... This is assuming that PyQt5 and PyQt6 are indeed close enough that it makes sense to implement support for both in a single module -- obviously, we'll only know that once PyQt6 is released.
The text was updated successfully, but these errors were encountered: