Repository navigation
ENH: call update_ticks before we return them to the user - #20345
jklymak wants to merge 2 commits into
Conversation
Sorry, something went wrong.
|
This one is pretty basic; if someone asks for the ticks on an axis, I don't see why we would force them to do a whole draw... |
Sorry, something went wrong.
timhoffm
left a comment
There was a problem hiding this comment.
That this is so basic makes me suspicious: Why haven't we done such a simple thing before?
My first guess "we use it heavily in the codebase (and it thus might be a performance issue)" is not correct. Apart from one usage in SecondaryAxis this is only used in tests an a tutorial. Why? Because internally we use get_minorticklocs() and get_majorticklocs(). Since both of them are public API as well, they should have the same update state as get_ticklocs(). I.e. if we update that should happen in there.
Now, I'm not sure what the implication of that would be. _update_ticks() queries get_minorticklocs() and get_majorticklocs() so we'd need to have a closer look on that cyclic usage. It might also be the case that we should make the current get_major/minorticklocs private for internal use without update and have change the public variants to use updates.
Anyway I'm afraid only adding _update_ticks() here is too simple.
Sorry, something went wrong.
|
I'm actually confused now what prompted this. Going back to 3.3.0 import matplotlib.pyplot as plt
import numpy as np
fig, ax = plt.subplots()
ax.plot(np.arange(100))
print(ax.xaxis.get_majorticklocs())
print(ax.xaxis.get_minorticklocs())
print(ax.get_xticks())works as expected. So I'll close this until we can remember why this was an issue. |
Sorry, something went wrong.
|
This was re-done by #23170, because it wasn't really working as stated above. |
Sorry, something went wrong.
PR Summary
Currently, get_x/yticks doesn't work until a draw is called. But we can update the ticks, so why not?
PR Checklist