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

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
Loading
from

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 for
making cycling sharable between multiple _process_plot_var_args instances,
which is the prerequisite for unifying the separate cyclers for lines and
patches (matplotlib#29468) and sharing cyclers between multiple Axes (matplotlib#19479).

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

@timhoffm timhoffm Jan 13, 2025

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 via staticmethod 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 a get_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
Member Author

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 free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.