| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Does this address the corresponding changes in tick_bottom/tick_top? |
Sorry, something went wrong.
|
@mwaskom Not yet - see todo list above... Note its also not working yet |
Sorry, something went wrong.
details, details... |
Sorry, something went wrong.
|
This definitely needs a test! |
Sorry, something went wrong.
|
@dstansby the test is easy if this is the behaviour we want. |
Sorry, something went wrong.
There was a problem hiding this comment.
This looks reasonable as a fix for the regression. I suspect there is no perfect fix. The underlying problem is that our API is complicated and confusing, with too many ways to do some things, and a lack of clarity such as is illustrated by the original docstring 'use ticks only on top'.
Sorry, something went wrong.
|
@efiring Yeah, I would actually be in favour of deprecating these functions due to their ambiguity. This PR at least tries to document the ambiguity, but its suboptimal. OTOH, the set_tick_params is pretty clear, if more syntactically verbose. |
Sorry, something went wrong.
|
Deprecation sounds good to me! It's hard to imagine that these vague shorthand versions are used so often in interactive mode, where their brevity would be most advantageous. |
Sorry, something went wrong.
Backport PR #9670 on branch v2.1.x
| Back | FazBrowse Home | New Git URL |
PR Summary
This modifies XAxis.tick_left and X-axis.tick_right to keep the tick labels turned off if the major
labels are already turned off.
Not 100% convinced this is the right thing to do, but fixes #9664 Wild guess is that this doesn't break anything, whereas the new behaviour did.
Fixes:
Breaks:
The following if the user expected tick_left() to turn the labeling back on.
I'm not sure why this would happen, but this PR breaks that case...
PR Checklist