Repository navigation
3.5.0b1 regression: boxplot does not populate ax.artists list #20895
Description
Bug summary
See title
Code for reproduction
import numpy as np
import matplotlib.pyplot as plt
X = np.random.randn(100, 5)
ax = plt.figure().subplots()
ax.boxplot(X, patch_artist=True)
assert ax.artistsActual outcome
AssertionError
Expected outcome
pass
Matplotlib Version
3.5.0b1
Installation
pip
Activity
mwaskom commentedon Aug 24, 2021
It looks like they patch artists have just moved,
assert ax.patchesfails on current release but passes on 3.5.0b1.ax.patchesis a better home for them, but it is going to be mildly annoying to deal with the change.QuLogic commentedon Aug 25, 2021
Yes, this is intentional; all
Artists are treated equally, and the.lines,.patches, etc are generated on the fly based on subclass. Aspatch_artist=Truecreates aPathPatch, it ends up inax.patches. Unfortunately, I don't think there's a quick workaround.mwaskom commentedon Aug 25, 2021
I think it may not be worth maintaining backwards compatibility here, although it is an abrupt break and will likely cause problems for someone. (I will need to fix some tests, although I don't think it will affect user-facing behavior...)
That said, one could imagine solutions for backwards compatibility ... e.g. methods with changed behavior could populate a special "deprecated" list, with metadata about where they used to go, then when the artist lists are constructed (on the fly, as accessed), they could pull in the appropriate deprecated artists and fire a warning.
It's late and I'm sleepy, so that might not be clear ... and it might not be worth the work. But perhaps worth considering ...
tacaswell commentedon Aug 25, 2021
When we put this in we had a conversation about either adding a tag to the objects as they came in to tell us which API they come in from to generate the back-compatible access lists or to filter on type. We went with filtering on type because it was simpler to implement (because no new state!) and because long-term it make more sense to say "
ax.lineshas all of the Line2D objects on the axes in it, no matter how it was added to the Axes" (basically a short-cut for the user filtering on type).We could do both, add a flag from the
add_*method so in the lists also include (and warn on access) the things that were added through the non-type patched method and are now landing in a different list. We would have to decide if we would want to the objects show up in bothax.artistsandax.patchesin this case (warning in the artists case) or have it just be in artists and later move it to just patches. I think we would want to have it in both for a while given the down-stream support concerns, but that comes at the cost ofax.artists + ax.patcheshaving duplicates.This also suggests that like we have a warning in
add_linefor adding non-line2D insstances we also need a test inadd_artistto warn about cases where this sort of thing will happen.mwaskom commentedon Aug 25, 2021
I'm actually kinda interested in what can be done with the on-the-fly artist lists in terms of providing smoother deprecation paths for the matplotlib artists used by higher-level libraries. There are some cases in seaborn where I either want to a) change the class of artist that gets generated or b) change the number of artists that get generated. But there is not currently a way I can think of to provide a warning about this to users who are accessing the artists directly for post-seaborn customization.
mwaskom commentedon Dec 31, 2021
Closing as 3.5 has been released.