Skip to content

Dropping support for PyQt4; preparing support for PyQt6. #16836

Closed
@anntzer

Description

@anntzer

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions