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

Refactoring: Removing axis parameter from scales#29988

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

Merged
QuLogic merged 25 commits intomatplotlib:mainfromvagnermcj:refactor-for-issue-29349
Jun 27, 2025

Conversation

vagnermcj
Copy link
Contributor

This PR addressesissue #29349 by refactoring built-in scale classes to make the axis parameter optional. The goal is to support future removal of axis while maintaining backward compatibility with current usage.

To achieve this, a decorator was introduced to allow constructors to accept or ignore axis. This was applied across all built-in scales. The scale_factory() function was updated to handle scale classes that do or do not use axis, and register_scale() now issues a deprecation warning if the constructor still expects it.

These changes prepare the codebase for eventual deprecation of axis in scale initializers, while avoiding any breaking changes in current usage.

My only doubt is which initializers for the scales should have the parameter as "axis = None". If all of them should have it, then i have to change the way my decorator works because axis could change position in parameters index

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 week or so, please leave a new comment below and that should bring it to our attention. 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.

@vagnermcjvagnermcj marked this pull request as ready for reviewApril 30, 2025 13:12
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.

Thanks for the PR. This is a bit tricky to get right in a backward-compatible and migration-easy way. I think we need to do it slightly differently.

@vagnermcj
Copy link
ContributorAuthor

Apologies for the sequence of commits — I wanted to ensure each feedback point was properly addressed and tested incrementally. Please let me know if this is the appropriate way to validate ruff, mypy-stubtest, and CI tests in general, or if you'd prefer a cleaner commit history or a different workflow.

I changed back the deprecation warning function, and changed the decorator as well. However, in the decorator i had many errors when trying to check "if args and isinstance(args[0], ScaleBase):", so instead of using ScaleBase as a reference i changed to "if args and isinstance(args[0], mpl.axis.Axis):". Does it make sense?

Let me know if anything else needs to be refined or if the structure of the changes could be improved further. Thanks again for your time and guidance throughout the review!

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.

Apologies for the sequence of commits — I wanted to ensure each feedback point was properly addressed and tested incrementally. Please let me know if this is the appropriate way to validate ruff, mypy-stubtest, and CI tests in general, or if you'd prefer a cleaner commit history or a different workflow.

It does not matter for small PRs. We'll typically review the full diff and squash-merge.

However, in the decorator i had many errors when trying to check "if args and isinstance(args[0], ScaleBase):", so instead of using ScaleBase as a reference i changed to "if args and isinstance(args[0], mpl.axis.Axis):". Does it make sense?

Yes. Sorry my bad for the incorrect suggestion.

Let me know if anything else needs to be refined or if the structure of the changes could be improved further. Thanks again for your time and guidance throughout the review!

You should add a test that the decorated scales can be created with and withoutaxis passed. - Either test on one of the scales, or write an explicit test for the decorator.

@vagnermcj
Copy link
ContributorAuthor

image

I started having this error with linting, but i don't understand why. It seems the error is in the _mathtext.py file, but i never changed it

@rcomer
Copy link
Member

rcomer commentedMay 29, 2025
edited
Loading

Looks like mypy just made a new release, so I suspect we will now see the same linting errors on all PRs. You can ignore them here.

vagnermcj reacted with thumbs up emoji

@vagnermcjvagnermcj requested a review fromtimhoffmJune 6, 2025 02:15
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.

Please leave out the unrelated typing modifications.

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.

This is good, except for one annotation toself.

@vagnermcj
Copy link
ContributorAuthor

Do i still need to make some change in the code? I see that it was accepted but some tests are failing

It's my first PR so i'm not sure 😅

@timhoffm
Copy link
Member

We require two reviews from core developers. The second one is still pending. IIRC the test failures were unrelated, but since the test runs have been cleaned up, you couldrebase onto main andforce-push.

vagnermcjand others added12 commitsJune 25, 2025 21:21
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
@vagnermcjvagnermcjforce-pushed therefactor-for-issue-29349 branch from223dc30 todabac62CompareJune 26, 2025 00:23
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
@QuLogicQuLogic merged commitc78c2f4 intomatplotlib:mainJun 27, 2025
41 checks passed
@QuLogicQuLogic added this to thev3.11.0 milestoneJun 27, 2025
@QuLogicQuLogic moved this fromWaiting for author toMerged inFirst Time ContributorsJun 27, 2025
@QuLogic
Copy link
Member

Thanks@vagnermcj! Congratulations on your first PR to Matplotlib 🎉 We hope to hear from you again.

vagnermcj reacted with hooray emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

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

@QuLogicQuLogicQuLogic approved these changes

@timhoffmtimhoffmtimhoffm approved these changes

Assignees
No one assigned
Projects
Milestone
v3.11.0
Development

Successfully merging this pull request may close these issues.

4 participants
@vagnermcj@rcomer@timhoffm@QuLogic

[8]ページ先頭

©2009-2025 Movatter.jp