Thanks for the PR! Good work, in particular the consideration if the initialization code path! However, I think this needs more careful consideration. The current tick mechanism it’s somewhat complicated.

First we have to distinguish between general default tick properties and those of individual ticks. If you set the color of individual ticks, future generated ticks are not affected. I’m away from my dev environment, so can’t check, but I guess the issue does not arise if you use ax.tick_params() in your example. This is the recommended way if you want to change a property of all ticks.

This should solve your use case, but of course not the case if someone wants to set the color of the first tick only. Conceptually, I’m unclear why set_position() needs to reset the ticks at all. I would have thought that moving the spine should not affect the ticks at all. Anyway, reapplying only the car solves the issue only for that property. However all other properties like font size and rotation will suffer from the same issue as well. So if you want to fix this we need a more general approach.

Also to be checked: #20805 should maintain tick properties after reset, but apparently doesn’t?!?

I’m unclear why set_position() needs to reset the ticks at all.

So this is due to the lazy instantiation of the ticks. If you change the color of each tick label, you instantiate the ticks, including their x/y position. If you subsequently move the spine, the ticks have already been instantiated, and the ticks don't come along with the spine unless you reset them.

Setting tick labels and their properties manually will always get invalidated if there is another change to the axis afterwards. What is more mysterious is that this sometimes works, because we instantiate a list of ticks that is empty before the axis is fully setup. So

fig, ax = plt.subplots()
ax.plot([1, 2, 3])
for lab in ax.get_yticklabels():
    lab.set_color("r")
ax.set_ylim([-1, 4])
plt.show()

will have red labels, because we set the empty labels to red, and then reused them.

So this is a real consistency problem, at least to my taste. I'd prefer the above and the original issue to error out, or evaluate the ticks properly, and populate with "real" ticks. If the user wants to change those, great. If the view changes, and the ticks are invalid, then their changes should be lost. I think all this would require is a state on the axis that says if the tick list is real or not (if we are unwilling to instantiate when needed for some reason), and then either error if there is no real list of ticks either create one, or Raise.

Yes, operating on single tick instances is almost never the right way to go. Ticks can change thoughout the lifetime of a figure. We need to make the gobal tick properties more a first class concept (we internally have that though _major_tick_kw). On the API (and maybe internal) side we should move away from single ticks. I have a pre-draft branch, that tries to wrap all that logic behind a fascade.

@hhalwan Thanks for looking into this. However I'm afraid you've poked quite a rabbit hole here and the correct solution has to go much deeper (Apart from the user side, which should use tick_params(labelcolor=...) and not iterate though the existing ticks).

@hhalwan I think this is probably not going to go in like this. But feel free to advocate for its inclusion if you strongly feel this would help users. The fundamental is that our tick interface is a) expensive, b) very flexible and c) very complicated.

Semi-related: #23372 - Use tick_params() instead of iterating over tick labels for setting tick properties

@hhalwan Sorry this didn't move forward, but as @timhoffm notes above this is a very complicated part of our code base. I'm going to close, but if you still feel strongly this can work, feel free to request a re-open. We very much hope to hear from you again!