8000 Avoid using `axis([xlo, xhi, ylo, yhi])` in examples. by anntzer · Pull Request #14149 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Avoid using axis([xlo, xhi, ylo, yhi]) in examples. #14149

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 1 commit into from
May 12, 2019

Conversation

anntzer
Copy link
Contributor
@anntzer anntzer commented May 7, 2019

In my view, axis() does too much: it can manipulate axis limits, axes
aspect ratio, lines and label visibility, etc.

This PR replaces in the examples axis([xlo, xhi, ylo, yhi]) by
set(xlim=(xlo, xhi), ylim=(ylo, yhi)) (or
plt.xlim(xlo, xhi); plt.ylim(xlo, yhi) for pyplot examples), which is
easier to intuit IMO.

There are also cases where I just remove the call to axis() when it
doesn't add much to the example.

Special cases:

  • anscombe can be greatly shortened by using shared axes. Note that
    the "old" xlims (2, 20) were immediately overwritten by xticks=(0, 10,
    20) which expanded the xlims to (0, 20)...
  • fonts_demo/fonts_demo_kw are better showcased using figtext() anyways.
  • In pcolor_demo, the call to axis() is unneeded (pcolor/pcolormesh
    correctly set the artist sticky edges to have the right bounds).
  • In pyplot_formatstr (which could probably be deleted...), the call
    to axis() does not showcase anything.
  • In slider_demo, margins(x=0) is semantically more correct.

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

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.

Not a big fan of the set() function, but it's at least more clear than axis().

Should we add a comment to axis() that it's recommended to set axes limits via set_x/ylim (or set(xlim=...))?

@timhoffm timhoffm added this to the v3.1.1 milestone May 11, 2019
@anntzer
Copy link
Contributor Author
anntzer commented May 11, 2019

I wouldn't bother for this PR, whose point is only to make the examples a bit more readable (to my taste at least).

@timhoffm
Copy link
Member
timhoffm commented May 11, 2019

Doesn't necessarily have to be within this PR. I was just wondering, if we don't want to use this pattern in the examples, maybe we should tell users that it's not the preferred way to do it. - Or do we want to leave it as an equally accepted way of working in the API? I don't think this will be deprecated ever, but maybe discouraged.

@anntzer
Copy link
Contributor Author
anntzer commented May 11, 2019

I added the alternate form in the docstring of axis(), but without indicating a preference for one form or the other.

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.

I'll merge as an improvement, though I don't particularly like ax.set(xlim=[x0, x1]) either

@timhoffm
Copy link
Member

I think this is ready to be merged. Not sure if this is only failing due to the pytest 4.5 issue. @anntzer can you please rebase?

In my view, `axis()` does too much: it can manipulate axis limits, axes
aspect ratio, lines and label visibility, etc.

This PR replaces in the examples `axis([xlo, xhi, ylo, yhi])` by
`set(xlim=(xlo, xhi), ylim=(ylo, yhi))` (or
`plt.xlim(xlo, xhi); plt.ylim(xlo, yhi)` for pyplot examples), which is
easier to intuit IMO.

There are also cases where I just remove the call to axis() when it
doesn't add much to the example.

Special cases:

- anscombe can be greatly shortened by using shared axes.  Note that
  the "old" xlims (2, 20) were immediately overwritten by xticks=(0, 10,
  20) which expanded the xlims to (0, 20)...
- fonts_demo/fonts_demo_kw are better showcased using figtext() anyways.
- In pcolor_demo, the call to axis() is unneeded (pcolor/pcolormesh
  correctly set the artist sticky edges to have the right bounds).
- In pyplot_formatstr (which could probably be deleted...), the call
  to axis() does not showcase anything.
- In slider_demo, margins(x=0) is semantically more correct.
@anntzer
Copy link
Contributor Author
anntzer commented May 12, 2019

rebased

@timhoffm
Copy link
Member

Thanks.

@timhoffm timhoffm merged commit 743052d into matplotlib:master May 12, 2019
@lumberbot-app
Copy link
lumberbot-app bot commented May 12, 2019

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

  1. Checkout backport branch and update it.
$ git checkout v3.1.x
$ git pull
  1. Cherry pick the first parent branch of the this PR on top of the older branch:
$ git cherry-pick -m1 743052d6bfdc9b23fe73ee2b5033639dc8642fab
  1. You will likely have some merge/cherry-pick conflict here, fix them and commit:
$ git commit -am 'Backport PR #14149: Avoid using `axis([xlo, xhi, ylo, yhi])` in examples.'
  1. Push to a named branch :
git push YOURFORK v3.1.x:auto-backport-of-pr-14149-on-v3.1.x
  1. Create a PR against branch v3.1.x, I would have named this PR:

"Backport PR #14149 on branch v3.1.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

@anntzer anntzer deleted the unaxis branch May 13, 2019 04:03
@tacaswell tacaswell modified the milestones: v3.1.1, v3.1.0 May 18, 2019
timhoffm added a commit to timhoffm/matplotlib that referenced this pull request May 18, 2019
@tacaswell tacaswell modified the milestones: v3.1.0, v3.1.1 May 18, 2019
tacaswell added a commit that referenced this pull request May 18, 2019
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
0