I still need to add a test.
The logic in axis.py is pretty hard to follow; some refactoring and renaming is probably in order, but the priority here is to come up with a minimally-invasive bugfix in time for 2.0.

Travis is failing because the original test_tightlayout.test_outward_ticks is incorrect owing to the bug that we are fixing. The bug was masked by the remove_text=True in the test decorator.

I have to ask… why was the _translate_tick_kw implemented? You seem to be the main author of this function, so you may remember. It's fairly old.

On 2016/09/15 4:16 PM, Nelle Varoquaux wrote:

I have to ask… why was the |_translate_tick_kw| implemented? You seem to
be the main author of this function, so you may remember. It's fairly old.

The problem was that long ago, when the Tick system was designed, it was
given a set of keyword arguments and corresponding attributes that
undoubtedly made sense at the time, but that were not ideal for an
end-user API. When I decided to write a convenience function for
modifying tick parameters, I wanted to give it nicer kwargs,
specifically designed to be suitable--readable and memorable, I
hope--for that function. Therefore I wrote _translate_tick_kw to map
the new kwargs to the old.

For example, this enables tick_params(top=True, labeltop=True)
instead of tick_params(tick2On=True, label2On=True).

Actually it goes beyond that because tick_params can work with xticks,
yticks, or both at the same time; separate functions would have been
needed for x and y if I had stuck with the original kwargs.

I haven't look at the code closely: would it be possible to remove this function and change the kwargs downstream in the code?

I should note that this is way out of the scope of this PR… just wondering for the future.

@NelleV Some amount of translation is still needed to handle the distinction between attributes of all ticks and attributes of x versus y ticks. Apart from that, we have the old backwards-compatibility constraint on the API to worry about.

The first step would be to alias them the other way.

It might be worth considering going the AxisArtist route and just re-implementeding axis + tick, backporting as much of the old API as reasonable, and then making the default class used for the axis + ticks configurable.

Thanks!