Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix for shared axes diverging after setting tick markers #10691

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

Closed
wants to merge 10 commits into from

Conversation

shaynair
Copy link

@shaynair shaynair commented Mar 5, 2018

PR Summary

This fixes issue #8946.
A previous pull request #10651 was made, but I erroneously rebased to master which messed up the commit history there.

Example plot:
https://i.imgur.com/jipvFh3.png

Associated code snippet to reproduce the above plot:

import matplotlib.pyplot as plt
fig, (ax1, ax2) = plt.subplots(2, sharex=True)
ax1.plot(range(0, 10), range(0, 10))
ax2.plot(range(0, 10), range(0, 10))
plt.xticks(range(0, 30))
plt.show()

The two plots should be identical as they share the x-axis, but clearly aren't. This is a fix for this.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 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

@jklymak jklymak added this to the v3.0 milestone Mar 5, 2018
@shaynair
Copy link
Author

shaynair commented Mar 7, 2018

Alright, I've incorporated the feedback given by @efiring. Please let me know what you think.

"""
If *ignore* is *False*, the order of vmin, vmax
does not matter; the original axis orientation will
be preserved. In addition, the view limits can be
expanded, but will not be reduced. This method is
expanded, but will not be reduced.
Copy link
Member

Choose a reason for hiding this comment

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

OK, while we are here, can we make these docstrings numpydoc compliant?

This file has almost no compliant docstrings (apparently it hasn't attracted the attention of @timhoffm, or he already has a PR in that hasn't been merged.)

As a random example of whats needed have a look at:

def add_axes(self, *args, **kwargs):

If you don't feel like doing this, its probably fine, but it'd help..

Copy link
Author

Choose a reason for hiding this comment

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

Should I make the entire file have compliant docstrings, or just the methods that I changed?

Copy link
Member

Choose a reason for hiding this comment

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

ha ha - go for the whole file if you want, but thats totally unfair. Just the strings you changed 😉

Copy link
Member

Choose a reason for hiding this comment

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

plus, if you think thats too annoying, don't feel obliged. Someone will hit the whole file soon I'm sure...

Copy link
Member

Choose a reason for hiding this comment

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

Did someone call me? 😉

@shaynair No seriously, only update the docstrings as part of this PR if you are touching them anyway. It simplifies the reviews if they are not too large and cover only one aspect. Also, keeping bugfixes and major docstring cleanups separate makes possible backports easier. That said, you are very welcome to open a separate PR for further docstring changes in the file.

Copy link
Author

Choose a reason for hiding this comment

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

Alright, I've updated it in my newest commit.

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.

This looks good to me. I think it needs a whats-new entry because you've added API, though I admit the API is somewhat obscure. Not sure if you need an example that uses the new API. I guess there are times when we don't want the two axes to share ticks, in which case you'd set emit=False.

@jklymak jklymak requested a review from efiring July 16, 2018 16:13
@tacaswell tacaswell modified the milestones: v3.0, v3.1 Jul 23, 2018
@jklymak
Copy link
Member

jklymak commented Feb 11, 2019

This is still a bug in master, but will require some rebasing. Punting to 3.2, but @shaynair keep pushing this if you want it to go in!

@jklymak jklymak modified the milestones: v3.1.0, v3.2.0 Feb 11, 2019
@jklymak
Copy link
Member

jklymak commented Jul 24, 2019

@shaynair sorry this has taken a while to get approval. Unfortunately the way our approval system works, stuff needs to be re-pinged frequently to attract attention.

This needs a rebase, and then we can ask @efiring to look again.

@jklymak jklymak added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Jul 24, 2019
@timhoffm
Copy link
Member

Tried to rebase this, but I'm afraid this is beyond repair. Too much changed in the meantime, so that it would be easier to rewrite from scratch. The test could be recovered to document the problem and be a starting point for a fresh solution.

@shaynair I'm very sorry, this got lost and we couldn't bring it into matplotlib.

@timhoffm
Copy link
Member

Test extracted, adapted and posted into the original issue: #8946 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API: consistency Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. status: needs rebase
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants