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
Explicit registration of canvas-specific tool subclasses. #20990
Conversation
Does the example still works? |
Yes, it works. |
_tool_registry = set() | ||
|
||
|
||
def _register_tool_class(canvas_cls, tool_cls=None): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how to do it easily, but I still need to ask, is it possible to add test to these two functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are covered already by existing tests (https://codecov.io/gh/matplotlib/matplotlib/compare/971d1106464560038151bf79d032515cd843b149...49d855f552bb44282b40ff689c5de5fe60ffbc15/diff).
@anntzer does it need a rebase? |
Don't mess up with overwriting backend_tools globals, which would fail if multiple backend modules are imported.
rebased |
Please note that the standard policy is two positive reviews before merging. |
Sorry, I saw Github requesting only one review, and I saw this as kind of small well contained change |
Explicit registration of canvas-specific tool subclasses.
Don't mess up with overwriting backend_tools globals, which would fail if multiple backend modules are imported.
This proposes an API to fix #17986 (and therefore unblock #20273 (comment)). I had tried another approach back in #9941, but that PR did many more cleanups at the same time and therefore got bogged down in side discussions; this one solely implements canvas-specific tool subclass registration. That registration mechanism is private for now, but we can always consider making it public if there's demand for it. (I actually guess there would not be that much demand for third-party tool implementers because even if the tool really required some backend-specific logic, it could just use a plain old if-switch instead (https://github.com/anntzer/mplinorm/blob/dbd0b34ab4b2ad3799410565ec6ad31f992b7576/lib/mplinorm.py#L162) because a single module/package would provide the tools; the dispatch problem on Matplotlib's side mostly comes from the fact that each backend implements its own tools in its own module. The only case where this would really be necessary for third parties is for integration into a new event loop.)
(See the linked PRs and issues for more details about the problem this is solving.)
attn @fariza, I guess.
PR Summary
PR Checklist
pytest
passes).flake8
on changed files to check).flake8-docstrings
and runflake8 --docstring-convention=all
).doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).