Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

neutrinoceros
Copy link
Contributor

@neutrinocerosneutrinoceros commentedSep 5, 2022
edited
Loading

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 (andpytest passes).
  • IsFlake 8 compliant (installflake8-docstrings and runflake8 --docstring-convention=all).

Documentation

  • New features are documented, with examples if plot related.
  • New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented indoc/api/next_api_changes/ (follow instructions in README.rst there).
  • Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).

Copy link

@github-actionsgithub-actionsbot 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 uson gitter for real-time discussion.

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

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

@tacaswelltacaswell added this to thev3.6.0 milestoneSep 6, 2022
Copy link
Member

@jklymakjklymak 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

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 keepstick_params(... width=10) underclear() whereas 3.6rc does not. I suppose this holds for a lot of the tick_params.

@neutrinoceros
Copy link
ContributorAuthor

neutrinoceros commentedSep 7, 2022
edited
Loading

@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
ContributorAuthor

@timhoffm done

Copy link
Member

@timhoffmtimhoffm 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 inimshow()? 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
ContributorAuthor

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
ContributorAuthor

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 testzorder
  • I doesn't combine nicely with other parameters I'm testing

I'll add a separate test and simplify this one

Copy link
ContributorAuthor

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 whatzorder=-1 issupposed to achieve, assuming the behaviour in matplotlib 3.5.3 isn't buggy. I would expect that combiningzorder=-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 combiningzorder=-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.

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

What's the policy for e.g.

  • zorder
  • the grid parameters likegrid_color

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

Copy link
ContributorAuthor

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
ContributorAuthor

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.

timhoffm reacted with thumbs up emoji
@neutrinoceros
Copy link
ContributorAuthor

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

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 intick_params() than documented. The documented ones are translated to tick properties, but we also accept tick properties directly.

@neutrinoceros
Copy link
ContributorAuthor

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

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 whatclear() 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.

neutrinoceros reacted with thumbs up emoji

@timhoffmtimhoffm marked this pull request as draftSeptember 8, 2022 21:39
@timhoffmtimhoffm added the status: needs comment/discussionneeds consensus on next step labelSep 8, 2022
@neutrinoceros
Copy link
ContributorAuthor

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

@timhoffmtimhoffm modified the milestones:v3.6.0,unassignedSep 9, 2022
@story645story645 modified the milestones:unassigned,needs sortingOct 6, 2022
@neutrinoceros
Copy link
ContributorAuthor

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
ContributorAuthor

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.

@neutrinocerosneutrinoceros deleted the hotfix_23806 branchOctober 4, 2023 12:36
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@timhoffmtimhoffmtimhoffm left review comments

@github-actionsgithub-actions[bot]github-actions[bot] left review comments

@tacaswelltacaswelltacaswell approved these changes

@jklymakjklymakjklymak approved these changes

Assignees
No one assigned
Labels
Projects
Milestone
future releases
Development

Successfully merging this pull request may close these issues.

5 participants
@neutrinoceros@timhoffm@tacaswell@jklymak@story645

[8]ページ先頭

©2009-2025 Movatter.jp