Skip to content

Factor out common limits handling for x/y/z axes. #21442

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 6, 2022

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Oct 23, 2021

The change in set_top_view is necessary because super().set_xlim no
longer goes to 2D semantics (it's on the Axis.set_view_limits that one
would need to do a supercall), but in any case the old behavior was
actually more buggy because it would e.g. confuse data-limits sharex and
2D projection sharex; e.g.
subplots(1, 2, sharex=True, subplot_kw={"projection": "3d"})
was previously wrong.

As a side effect, also fixes invert_yaxis/invert_zaxis on 3d axises (#21369)
(because they just go to the base Axis.set_inverted). Redoing the inheritance
hierarchy (#21424) would probably(?) still be nice, at least from a semantic PoV.

old bad 3d sharex:
old

PR Summary

PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

@anntzer anntzer added this to the v3.6.0 milestone Oct 23, 2021
@anntzer anntzer force-pushed the xyzlim branch 2 times, most recently from f840d22 to e463b79 Compare October 25, 2021 23:12
*xmax* respectively; *emit* and *auto* are used as is.
"""
v0name, v1name = names # The value names.
name, = [name for name, axis in self.axes._get_axis_map().items()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a really obscure way to get the name to me. Is there some reason an axis can't know its "name" when it is created?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Axises know their "name", but that's e.g. "r"/"theta" for polar axes whereas here we really want "x"/"y" even for polar. Perhaps Axises should have multiple name attributes for the various use cases, but that would be a bit hairy too...

Copy link
Member

@jklymak jklymak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall 👍 - centralizing this makes sense, even if the root code is a little hared to parse, but the comments all help. Needs a rebase, and maybe a bit of thought about where "names" comes from - feel free to ping for a re-review.

@anntzer
Copy link
Contributor Author

anntzer commented Feb 4, 2022

Rebased.

@anntzer anntzer force-pushed the xyzlim branch 2 times, most recently from 112c294 to 56cf49d Compare February 5, 2022 20:56
Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May self-merge after adressing the one remaining comment.

# rather than generically using set_view_interval, so that shared
# axes get updated as well.
raise NotImplementedError('Derived must override')
# docstring inherited
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't have that comment and a docstring. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, fixed.

The change in set_top_view is necessary because super().set_xlim no
longer goes to 2D semantics (it's on the Axis.set_view_limits that one
would need to do a supercall), but in any case the old behavior was
actually more buggy because it would e.g. confuse data-limits sharex and
2D projection sharex; e.g.
`subplots(1, 2, sharex=True, subplot_kw={"projection": "3d"})`
was previously wrong.

As a side effect, also fixes `invert_yaxis`/`invert_zaxis` on 3d axises
(because they just go to the base `Axis.set_inverted`).
@timhoffm
Copy link
Member

timhoffm commented Feb 6, 2022

Doc failures are real.

The "canonical" property names for Axes3D were switched from
xlim3d/ylim3d to xlim/ylim so that Axes3D can directly inherit the
setters from 2D Axes.
@anntzer
Copy link
Contributor Author

anntzer commented Feb 6, 2022

Test failure should be fixed now; foc failures seem related to the new scipy 1.8 release?

@timhoffm timhoffm merged commit 99de892 into matplotlib:main Feb 6, 2022
@anntzer anntzer deleted the xyzlim branch February 6, 2022 19:37
@QuLogic
Copy link
Member

QuLogic commented Feb 9, 2022

This broke docs (see failed build in #22431):

.../lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.get_xlim:20: WARNING: py:obj reference target not found: set_xlim
.../lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.get_ylim:20: WARNING: py:obj reference target not found: set_ylim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants