Skip to content

BUG: fix a regression where tick direction wasn't conserved by Axis.clear() #23808

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 3 commits into from

Conversation

neutrinoceros
Copy link
Contributor

@neutrinoceros neutrinoceros commented Sep 5, 2022

PR Summary

This is a quick fix for #23806, assuming the change in behaviour I reported there wasn't intentional

PR Checklist

Tests and Styling

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

  • New features are documented, with examples if plot related.
  • 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).
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

Thank you for opening your first PR into Matplotlib!

If you have not heard from us in a while, please feel free to ping @matplotlib/developers or anyone who has commented on the PR. Most of our reviewers are volunteers and sometimes things fall through the cracks.

You can also join us on gitter for real-time discussion.

For details on testing, writing docs, and our review process, please see the developer guide

We strive to be a welcoming and open project. Please follow our Code of Conduct.

@tacaswell tacaswell added this to the v3.6.0 milestone Sep 6, 2022
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.

Will hold off merging if @timhoffm wants to argue this is wrong, unless we are pushing 3.6 final out the door imminently...

@timhoffm
Copy link
Member

timhoffm commented Sep 7, 2022

It's ok to go back to 3.5 behavior for this. But we need to consider other parameters as well. For example, 3.5 also keeps tick_params(... width=10) under clear() whereas 3.6rc does not. I suppose this holds for a lot of the tick_params.

@neutrinoceros
Copy link
Contributor Author

neutrinoceros commented Sep 7, 2022

@timhoffm I'm happy to extend the scope of my PR as needed. Should I parametrise my test or extend it so it covers many parameters at once ?

edit: never mind I see that you already answered my question in the issue, I'll work on this now

@neutrinoceros
Copy link
Contributor Author

@timhoffm done

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.

I'm sorry this is such a mess. Let me at least recap the history:

The target should be preserving the 3.4.3/3.5.x state for. Maybe we should back out #22587 for 3.6 and defer to 3.7. It's only supposed to be a code cleanup after all. Otherwise, I think we need even better tests to ensure we're doing consistent and right things.


ax = fig_ref.subplots(1, 1)
ax.tick_params(**params)
ax.imshow(img)
Copy link
Member

Choose a reason for hiding this comment

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

Is there an advantage in imshow()? I would have expected that an empty plot would work just as well. - Advantage: We save 4 unneeded lines of code and the resulting plot is less cluttered.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's for testing zorder. If the plot is otherwise empty we can't detect when it's broken. I'll add a comment to clarify this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

come to think of it:

  • I actually forgot to actually test zorder
  • I doesn't combine nicely with other parameters I'm testing

I'll add a separate test and simplify this one

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I don't think I understand what zorder=-1 is supposed to achieve, assuming the behaviour in matplotlib 3.5.3 isn't buggy. I would expect that combining zorder=-1, direction='in' with an image would effectively hide ticks behind the image, but it's not the case. In order to keep this PR on the conservative side, I'm not going to change the behaviour here unless required.

Copy link
Member

Choose a reason for hiding this comment

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

I would expect that combining zorder=-1, direction='in' with an image would effectively hide ticks behind the image, but it's not the case

I would share that expectation

In order to keep this PR on the conservative side, I'm not going to change the behaviour here

👍

@@ -846,6 +846,13 @@ def get_children(self):
return [self.label, self.offsetText,
*self.get_major_ticks(), *self.get_minor_ticks()]

# style parameters that should be preserved by reset operations
Copy link
Member

Choose a reason for hiding this comment

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

This looks better, but I'm a bit of a loss what we actually want.

What's the policy for e.g.

  • zorder
  • the grid parameters like grid_color

We should have an explicit statement on why we keep some parameters but not others.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I intentionally left out grid params because I have no opinion there, but I agree it should be discussed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

zorder seemed to fit in the "visibility" theme, for which a consensus appears to have been reached. Please correct me if I am wrong.

@neutrinoceros
Copy link
Contributor Author

Otherwise, I think we need even better tests to ensure we're doing consistent and right things.

I'm all for that, but could you clarify what you have in mind ?

@timhoffm
Copy link
Member

timhoffm commented Sep 8, 2022

Otherwise, I think we need even better tests to ensure we're doing consistent and right things.

I'm all for that, but could you clarify what you have in mind ?

Essentially covering all parameters and making sure that the behavior is consistent before and after #22587 (or 3.5.x and main); i.e. all parameters that we're cleared before should be cleared now, and all parameters that were kept before should be kept now. An additional annoyance to that is that we accept more paramters in tick_params() than documented. The documented ones are translated to tick properties, but we also accept tick properties directly.

@neutrinoceros
Copy link
Contributor Author

I absolutely agree with you, I'm just not sure I'll have the time to dig much further into this. I may, but in the mean time, please feel free to add to this PR if you feel that's appropriate.

@timhoffm
Copy link
Member

timhoffm commented Sep 8, 2022

The dev call today we have decided to revert the last change. This will continue the behavior for 3.5 to 3.6. For 3.7 we plan a discussion on what clear() actually should do.

@neutrinoceros thanks for this PR, I'll mark it as draft as it needs some changes after the rebase, but the tests will continue to be usful. Until we had the discussion there is not much you can do in this PR.

@timhoffm timhoffm marked this pull request as draft September 8, 2022 21:39
@timhoffm timhoffm added the status: needs comment/discussion needs consensus on next step label Sep 8, 2022
@neutrinoceros
Copy link
Contributor Author

Thank you for your work, I really appreciate it !
If I understand correctly this PR should be removed from the 3.6 milestone 🙂

@timhoffm timhoffm modified the milestones: v3.6.0, unassigned Sep 9, 2022
@story645 story645 modified the milestones: unassigned, needs sorting Oct 6, 2022
@neutrinoceros
Copy link
Contributor Author

Do you guys wish to keep this open until the discussion is had ? I'm thinking maybe the test could be merged by itself ? I'm fine either way, I'm just trying to cleanup my personal backlog.

@tacaswell
Copy link
Member

This is unfortunately still in limbo.

@neutrinoceros
Copy link
Contributor Author

It does not seem necessary anymore, so I'll close this. If it ever changes, anyone is free to continue this work and take off where I left.

@neutrinoceros neutrinoceros deleted the hotfix_23806 branch October 4, 2023 12:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

5 participants