ENH: add axisbelow option 'line', make it the default

[efiring]

The present axisbelow value can be only True, which puts the ticks and gridlines below patches, or False, which puts them above lines. It might make more sense to put them above patches (e.g. filled contours) and below lines. This PR adds that option, and makes it the default. See #5980 and #4243.

Ideally we would be able to control ticks and gridlines separately, as requested in #4243, but this would require major refactoring. Ticklines and gridlines are drawn by Tick.draw which is called by Axis.draw. Hence the order in which they are drawn relative to other plot elements is controlled by Axes.xaxis.zorder etc., not by the zorder of each gridline, for example.

[tacaswell]

also need to change in the template

[tacaswell]

I am moderately 👍 on this. Would it be better to let the rcparam be a float ?

[efiring]

I thought about the float option, but using strings fits better with the (perhaps unfortunate) existing name of the parameter/kwarg. "axisbelow line" makes a little bit of sense; "axisbelow 1.5" doesn't.
I originally took a stab at setting zorder of the gridlines, but it didn't work, for the reason given in the commit comment above.

[efiring]

There are 3 image failures involving minuscule differences. In the one I reproduced, I can't even see anything other than solid black in the diff image. I would not expect this PR to affect any images because the classic style is unchanged.

[WeatherGod]

I have been seeing tiny image comparison failures locally. The diff images
show me all black, too.

On Sun, Apr 10, 2016 at 11:07 PM, Eric Firing notifications@github.com
wrote:

There are 3 image failures involving minuscule differences. In the one I
reproduced, I can't even see anything other than solid black in the diff
image. I would not expect this PR to affect any images because the classic
style is unchanged.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#6287 (comment)

[tacaswell]

did some of the pgf tests avoid getting run in 'classic' mode?

[jenshnielsen]

Yes the pgf tests have their own slightly different image comparison for some reason. They will not run in classic mode

[efiring]

The one Travis failure is in the docs build. I don't understand it.

[efiring]

The Travis failure is in the docs build, ./examples/api/custom_scale_example.py. That's a pretty complicated example, but I don't see how its failure could be related to the present PR. @mdboom, any ideas?

[efiring]

The example fails with rcParams['axes.axisbelow'] = True as well as with the new default, so it has always been broken--this PR is just triggering the failure.
The line in the example that triggers the failure (which occurs at draw time) is plt.ylabel('Latitude').

[efiring]

I think this is complete now. The last thing I added is a note in whats_new/style_changes. The change is visually so subtle that maybe it doesn't need to be mentioned here; if that's the case, the last commit can be removed.

[mdboom]

👍 after adding a test.

[tacaswell]

backported to v2.x as 2ec3780