-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Don't expose private styles in style.available #30235
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
Conversation
lib/matplotlib/style/__init__.py
Outdated
available[:] = sorted(library.keys()) | ||
library.update(_update_user_library(_base_library.copy())) | ||
available[:] = sorted(name for name in library | ||
if not name.startswith('_') or name not in _base_library) |
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.
Ok, so the idea is that we only exclude "_name" styles that are in the base library. Any other styles in the base library are shown, and any user styles are shown. I got that right?
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 would l go for: Exclude all styles with leading _. Not sure why users would register such styles, but let’s just document this way. It’s more in line with general underscore semantics , e.g. dir()
and simpler to implement.
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.
Agreed. What if other libraries need to register their own "private" styles?
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.
My take: Private styles are those with a leading underscore. Everybody can register and get/use them. They are only not listed under the available styles. This is the same logic as with private attributes/methods.
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.
Yes, the only reason I wrote it this way is because the test adds a _test_
style and looks for it in available
. But as I've now fixed reload_library
to correctly clean up user styles, I think we can use any name in the test.
They remain in `style.library`, because that's how we look them up, but this prevents them being exposed as something someone might use. Also, fix `reload_library`, which was accidentally modifying the original base library information each time. Fixes itprojects/MasVisGtk#13
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.
Ok. Though, I think we should move away from "bunch of functions and variables" to a StyleRegistry
concept, similar to ColormapRegistry
.
I consider this a bug fix, so pointing to 3.10.x |
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the If these instructions are inaccurate, feel free to suggest an improvement. |
Not worth a manual backport. |
PR summary
They remain in
style.library
, because that's how we look them up, but this prevents them being exposed as something someone might use.Also, fix
reload_library
, which was accidentally modifying the original base library information each time.Fixes itprojects/MasVisGtk#13
PR checklist