So the bug comes from the fact that plt.setp(... visible=False) set the visibility by calling tick.set_visible(False), which used to override tick_params() which would set reset label1On to True; but after#10088 label1On maps to set_visible and thus the call to tick_params undoes the call to set_visible(False).

I think a correct fix would be somewhere along the lines of

diff --git i/lib/matplotlib/axis.py w/lib/matplotlib/axis.pyindex 127c9c5b0..094cd53fd 100644--- i/lib/matplotlib/axis.py+++ w/lib/matplotlib/axis.py@@ -856,26 +856,16 @@ class Axis(martist.Artist):         For documentation of keyword arguments, see         :meth:`matplotlib.axes.Axes.tick_params`.         """-        dicts = []-        if which == 'major' or which == 'both':-            dicts.append(self._major_tick_kw)-        if which == 'minor' or which == 'both':-            dicts.append(self._minor_tick_kw)         kwtrans = self._translate_tick_kw(kw)-        for d in dicts:-            if reset:-                d.clear()-            d.update(kwtrans)-         if reset:             self.reset_ticks()         else:             if which == 'major' or which == 'both':                 for tick in self.majorTicks:-                    tick._apply_params(**self._major_tick_kw)+                    tick._apply_params(**kwtrans)             if which == 'minor' or which == 'both':                 for tick in self.minorTicks:-                    tick._apply_params(**self._minor_tick_kw)+                    tick._apply_params(**kwtrans)             if 'labelcolor' in kwtrans:                 self.offsetText.set_color(kwtrans['labelcolor'])         self.stale = True

plus some wrangling with the rest of the codebase to keep track of label1On-ness.

Release critical as a regression.

If I recall correctly, I had tried something like the simpler diff you presented here, but got several new test failures as a result. It may very well be easy to track those down in a cleaner way, though my inital efforts focused on fixing the problem fairily locally.

I think a simpler approach may be possible but this looks generally ok as a stopgap if nothing better is proposed before 3.1.

I am concerned about this fix. The underlying issue here is that the tick system has an internal set of defaults that it uses to create new ticks, but by usingplt.setp you are reaching in to change the state of the ticks without propagating that back the default dictionary. This skip-list works for visibility, but will not work for color (or any other property).
Doing

ax.tick_params(axis="y",which="both",label1On=False)ax.tick_params(axis="y",which="both",length=0)

works as expected.

I am 👎 on merging this. The correct fix is to track on the tick objects what state has been touch independently by the user and then not update that property.

I am also concerned that this will not work in the case where we generate more tick objects later so you will end up with mixed state.

It might be possible to use theget methods to check what state does not match the (previous) defaults and then skip applying based on that?

To be clear, this is just taking out arguments only in the case that they were not asked for explicitly and simply not trying to change it. If the user is modifying the state using this function, those changesare propegated.

That said, I make no illusions, this is a hack, and there are certainly cleaner solutions, including changing my own library code such that thelabelOn, etc. get set to match.

The point about mixed state is a good one, however, if users intentionally got a mixed state (I would tend to avoid this myself, but still) The code without this patch will override that mixed state, even when the arguments that are written have nothing to do with visibility.

The way this is implemented preserves mixed state if it exists, but makes it easy to get back to a consistent state.

Sorry, being thrashy about milestones / tags... Still thinking about this.

I applied half of the diff suggested in the comments by@anntzer (we still want to update the default settings fornew ticks) but only apply the passed-in kwargs to the existing ticks.

If I recall correctly, I had tried something like the simpler diff you presented here, but got several new test failures as a resul

@ksunden what tests failed for you locally with this change?

Went back and forth a bit on trying to understand what the intent of this method is (as it could be argued that the correct behavioris to re-apply the standard style to all of the ticks), but the presence of thereset kwargs suggests otherwise.

I am not getting any local test failures now, I recall trying this back in november, but don't recall why I ultimately moved on from it. All looks good on my end now.

Something went wrong ... Please have a look at my logs.