Axes.invert_xaxis() / Axes.invert_yaxis(). Use ax.xaxis.set_inverted(bool) instead.
Axes.xaxis_inverted() / Axes.yaxis_inverted(). Use ax.xaxis.get_inverted() instead.
These are simple and rare enough so that we do not need to lift the API from the Axis to the Axes.
I'm still not decided whether we should only discourage or deprecate. - It's the usual trade-off between backward-compatibility and making the API simpler / less redundant.
I'm kinda surprised there isn't an Axes.invert(which={x, y, both}) method since that seems like it'd be more consistent with the other methods on axes. Also what I'd propose replacing invert_{xy}axis with if you're going to deprecate those so there is still a method on axes and it is therefore discoverable in those docs.
My problem with this is the axis API page is somewhat hard to discover. Maybe the API top level page needs to mention this and a couple other modules as being key to understanding the library (we have Axes and Figure already mapped out pretty well)
The problem of Axes.invert (or Axes.invert_xaxis) is that it can easily make code less robust, because if you factor out your block of code into a library function that takes an ax parameter, things will typically go wrong if the axis was already inverted to start with (see the changelog entry in #13330). So I think we should just encourage the more robust pattern (set_inverted(True)).
I think invert_xaxis has been around for long enough that we should just discourage it without deprecating it.
can this be added as a kwarg to .set_tick_params? Also then what about Axes.inverted(inverted=False, which='both') which mirrors grid and calls out to set_inverted
.set_tick_params` also includes bulk operations on ticks and this flips them? though I do hear you that that might be pushing the scope of that function too far.
To make the discussion short, with my API authority I claim: We're not going to introduce any new Axes-level API for this. It's either the existing methods or going down to Axis via ax.xaxis / ax.yaxis.
Sorry for being terse, I can motivate this in detail if there is interest, but I don't have the time right now.
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
Activity
story645 commented on Aug 15, 2022
I'm kinda surprised there isn't an Axes.invert(which={x, y, both}) method since that seems like it'd be more consistent with the other methods on axes. Also what I'd propose replacing invert_{xy}axis with if you're going to deprecate those so there is still a method on axes and it is therefore discoverable in those docs.
jklymak commented on Aug 16, 2022
My problem with this is the axis API page is somewhat hard to discover. Maybe the API top level page needs to mention this and a couple other modules as being key to understanding the library (we have Axes and Figure already mapped out pretty well)
anntzer commented on Aug 18, 2022
The problem of Axes.invert (or Axes.invert_xaxis) is that it can easily make code less robust, because if you factor out your block of code into a library function that takes an ax parameter, things will typically go wrong if the axis was already inverted to start with (see the changelog entry in #13330). So I think we should just encourage the more robust pattern (set_inverted(True)).
I think invert_xaxis has been around for long enough that we should just discourage it without deprecating it.
story645 commented on Aug 18, 2022
can this be added as a kwarg to .set_tick_params? Also then what about Axes.inverted(inverted=False, which='both') which mirrors grid and calls out to set_inverted
anntzer commented on Aug 18, 2022
It's certainly not a tick param. I guess I don't really like Axes.inverted(bool, which=...), but I probably don't feel as strongly about it.
story645 commented on Aug 18, 2022
.set_tick_params` also includes bulk operations on ticks and this flips them? though I do hear you that that might be pushing the scope of that function too far.
anntzer commented on Aug 18, 2022
Not really, at least not any more than plot([3, 4]) is a ticks operation in that it sets visible ticks at 3 and 4, I would say.
timhoffm commented on Aug 19, 2022
To make the discussion short, with my API authority I claim: We're not going to introduce any new Axes-level API for this. It's either the existing methods or going down to Axis via ax.xaxis / ax.yaxis.
Sorry for being terse, I can motivate this in detail if there is interest, but I don't have the time right now.
story645 commented on Aug 19, 2022
I think consensus is discourage not deprecate - Jody and me for discoverability reasons, Anthony 'cause it's too widely used?
github-actions commented on Dec 19, 2025
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
timhoffm commented on Dec 19, 2025
Closed by #29074.