Fix compatibility with Matplotlib 3.5 #7301
Conversation
The problem was `qiskit.visualization.bloch.Arrow3D`, which subclassed `matplotlib.patches.FancyArrowPatch` (a 2D patch), but not the 3D machinery. It is now made an unholy multiple-inherited abomination of both the 2D patch and `mpl_toolkits.mplot3d.art3d.Patch3D`; the latter is a relatively thin wrapper (in terms of attributes) around the 2D patch, so this is not too terrible. Matplotlib 3.5 calls the `Patch3D.do_3d_projection` method using a deprecated parameter, triggering two warnings, unless the artist's module appears to have come from `mpl_toolkits.mplot3d.art3d`, even if the new calling convention is respected. The warning is only triggered when the figure is drawn, which may well be outside of our control, so we cannot suppress the warnings. Instead, we just lie about the module the arrow patch was defined in, to trick it into not warning, because we use the new calling convention. This is supported at least as far back as Matplotlib 3.3, which is the current minimum supported version. The nasty hack should be removable once Matplotlib 3.6 is the minimum version because the deprecation period will expire.
jakelishman
added
priority: high
Changelog: Bugfix
jakelishman
requested review from
nkanazawa1989,
nonhermitian and
a team
as code owners
Pull Request Test Coverage Report for Build 1496098524
💛 - Coveralls |
There was a problem hiding this comment.
LGTM, one inline comment typo to fix. I really do think this is worth opening an issue in mpl about (if you haven't already) since this seems like a pretty broken migration/deprecation plan for people. Especially since the Arrow3D code is basically identical in every search result for "3d arrow matplotlib".
| # well, which consequently triggers another deprecation warning. We should be able to remove | ||
| # this once 3.6 is the minimum supported version, because the deprecation period ends then. |
There was a problem hiding this comment.
Fwiw, it'll be a while before we can make our matplotlib requirement >=3.6.
There was a problem hiding this comment.
Yeah I know - here it's just that I don't like putting in gross hacks without saying the condition that they can be removed again!
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
|
Yeah, I'll make the issue on MPL. I didn't before because I didn't know enough about what was going on, but I've read the |
Summary
The problem was
qiskit.visualization.bloch.Arrow3D, which subclassedmatplotlib.patches.FancyArrowPatch(a 2D patch), but not the 3Dmachinery. It is now made an unholy multiple-inherited abomination of
both the 2D patch and
mpl_toolkits.mplot3d.art3d.Patch3D; the latteris a relatively thin wrapper (in terms of attributes) around the 2D
patch, so this is not too terrible.
Matplotlib 3.5 calls the
Patch3D.do_3d_projectionmethod using adeprecated parameter, triggering two warnings, unless the artist's
module appears to have come from
mpl_toolkits.mplot3d.art3d, even ifthe new calling convention is respected. The warning is only triggered
when the figure is drawn, which may well be outside of our control, so
we cannot suppress the warnings. Instead, we just lie about the module
the arrow patch was defined in, to trick it into not warning, because we
use the new calling convention. This is supported at least as far back
as Matplotlib 3.3, which is the current minimum supported version. The
nasty hack should be removable once Matplotlib 3.6 is the minimum
version because the deprecation period will expire.
Details and comments
This isn't neat or pretty, but it's an attempt to keep the behaviour exactly as it has been ever since this file came from qutip, since I don't understand
mplot3dvery well. Fix #7272.