8000 Regression: undocumented change of behaviour in mpl 3.4.2 with axis ticks direction · Issue #20219 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

Regression: undocumented change of behaviour in mpl 3.4.2 with axis ticks direction #20219

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
neutrinoceros opened this issue May 13, 2021 · 11 comments · Fixed by #20826
Closed

Regression: undocumented change of behaviour in mpl 3.4.2 with axis ticks direction #20219

neutrinoceros opened this issue May 13, 2021 · 11 comments · Fixed by #20826
Labels
status: confirmed bug
Milestone
v3.4.3

Comments

@neutrinoceros
Copy link
Contributor

Bug report

Bug summary

Ticks direction set with Axes.tick_params used to be persistent but is now erased by Axes.cla().
Maybe this change is actually intended ? in any case I couldn't find a mention of it in your release notes so I'm considering it a bug for now.

Code for reproduction

I originally detected a regression in yt, see yt-project/yt#3256
I was able to reproduce the change of behaviour with the following minimal script

import matplotlib.pyplot as plt

from matplotlib import __version__ as mplver

fig, ax = plt.subplots()
ax.tick_params(direction="in")
ax.cla()
fig.savefig(f"/tmp/mpl_{mplver}_regr.jpg")

Actual outcome

This is with matplotlib 3.4.2

mpl_3 4 2_regr

Expected outcome

This is with matplotlib 3.4.1
mpl_3 4 1_regr

Matplotlib version

  • Operating system: OSX
  • Matplotlib version (import matplotlib; print(matplotlib.__version__)): see above
  • Matplotlib backend (print(matplotlib.get_backend())): MaxOSX
  • Python version: 3.9

installed from pypi with pip
This was referenced May 13, 2021
Merged
Closed
@jklymak
Copy link
Member
jklymak commented May 13, 2021

This bisects to #20161 @timhoffm if you had a chance to take a look? It looks like resetting all the kwargs in clear was too aggressive.

@tacaswell
Copy link
Member

I think there is a strong case that the 3.4.1 behavior was buggy (as ax.cla() should set the axes back to its "fresh" state).

This is one of the fun things of working on a widely used library: all possible observed behavior eventually becomes a feature to at least one user (see https://xkcd.com/1172/)!

If you want to have the default direction of the ticks be in I would use

import matplotlib.pyplot as plt
plt.rcParams['xtick.direction'] = plt.rcParams['ytick.direction'] = 'in'

@neutrinoceros
Copy link
Contributor Author

I'm fine either way, though if you're considering it a bugfix I think it should be documented as such :-)

@neutrinoceros
Copy link
Contributor Author

@jklymak @tacaswell is there any relevant change or discussion about this ? should the new behaviour just be regarded as the new standard onwards ?

@jklymak
Copy link
Member
jklymak commented Aug 5, 2021

I guess it depends on whether other tick params are persistent or not. Similarly other axes amd axis properties. If I change the face color does that reset in cla? I thought that cla simply removed any artists and reset any limits, but you could imagine it also scrubbing any axes styling.

@tacaswell
Copy link
Member

@neutrinoceros I'm still pretty convinced that the ticks not getting re-set was a bug and ax.cla() should take it back to an identical state to as when it was created. This is in part because it is easy to document and understand ("it makes it like new!" is simpler than "It makes it like new except for....") and because we use self.cla() as part of the initialization process of Axes.

@neutrinoceros
Copy link
Contributor Author

@tacaswell this makes sense to me. Should I move forward and open a PR to document this as the canonical/expected behaviour ?

@jklymak
Copy link
Member
jklymak commented Aug 5, 2021 
import matplotlib.pyplot as plt
import numpy as np
import matplotlib as mpl

fig, ax = plt.subplots()
ax.set_facecolor('r')
ax.cla()
plt.show()

shows a red axes, so I don't think its true that clearing the axes gives us a "new" axes; it clears the children.
8000

@tacaswell
Copy link
Member

Maybe we should document cla as

Clears the Axes

This will remove all of the children and reset many of the style parameters
of the Axes and Axis.

and also add a retro-active behavior change note to https://github.com/matplotlib/matplotlib/blob/master/doc/api/prev_api_changes/api_changes_3.4.2.rst

If someone where to report Jody's example as a bug I would agree it was a bug. On the other had I bet the behavior has been like that forever and we do not want to wantonly break users.

@jklymak
Copy link
Member
jklymak commented Aug 6, 2021

I think we should specify which properties will be reset and not change them arbitrarily. I think "some properties" is too vague.

Axes.cla does lots of stuff, much of which seems concerned with initial setup of the axes. But it does try to explicitly preserve a bunch of things as well.

@tacaswell
Copy link
Member

I think we should specify which properties will be reset and not change them arbitrarily.

You are right, but I do not like it.

@tacaswell tacaswell mentioned this issue Aug 9, 2021
Merged
3 tasks
@QuLogic QuLogic mentioned this issue Aug 11, 2021
Merged
2 tasks
@QuLogic QuLogic added this to the v3.4.3 milestone Aug 11, 2021
@jklymak jklymak mentioned this issue Sep 9, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: confirmed bug
Projects
None yet
Milestone
v3.4.3
Development

Successfully merging a pull request may close this issue.

Fix clear of Axes that are shared. QuLogic/matplotlib
4 participants
@tacaswell @QuLogic @jklymak @neutrinoceros
0