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

MNT: Separate property cycle handling from _process_plot_var_args#29469

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

Open
timhoffm wants to merge1 commit intomatplotlib:main
base:main
Choose a base branch
Loading
fromtimhoffm:extract-prop-cycle

Conversation

timhoffm
Copy link
Member

By encapsulating the cycling into a dedicated class, we prepare for making cycling sharable between multiple _process_plot_var_args instances, which is the prerequisite for unifying the separate cyclers for lines and patches (#29468) and sharing cyclers between multiple Axes (#19479).

By encapsulating the cycling into a dedicated class, we prepare formaking cycling sharable between multiple _process_plot_var_args instances,which is the prerequisite for unifying the separate cyclers for lines andpatches (matplotlib#29468) and sharing cyclers between multiple Axes (matplotlib#19479).

def _setdefaults(self, defaults, kw):
@staticmethod
Copy link
MemberAuthor

@timhoffmtimhoffmJan 13, 2025
edited
Loading

Choose a reason for hiding this comment

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

This is not strictly related, but noticed that_setdefaults does not depend on the class, so making that explicit viastaticmethod as an improvement on the side.

@cvanelteren
Copy link

Hi, just wanted to chip in that we are facing similar issues that it is a bit opague how the cycling is handled. In our case we would also need aget_next_item next to the color; could this be added to this PR? It would make the cycling handling more robust without resorting to the manual cycling we are currently doing in UltraPlot.

@timhoffm
Copy link
MemberAuthor

Thanks for the feedback. This PR is an internal refactoring and since we currently don’t need that function. I won’t add it to the PR. After all, this is all internal for now and we reserve the right to change everything. Even if I would add the function you could not rely that it will be available and have a defined API.

That said, this is part of a larger plan to make cycling more flexible. I plan to make the cycle in the Axes accessible as public API, which also includes the ability to get the next element.

@cvanelteren
Copy link

Ok thanks for clarifying. Then I will proceed with our internal cycling for now.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@timhoffm@cvanelteren

[8]ページ先頭

©2009-2025 Movatter.jp