Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
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, andany 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 inavailable. But as I've now fixedreload_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, butthis prevents them being exposed as something someone might use.Also, fix `reload_library`, which was accidentally modifying theoriginal base library information each time.Fixesitprojects/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 aStyleRegistry concept, similar toColormapRegistry.
I consider this a bug fix, so pointing to 3.10.x |
b6777b1 intomatplotlib:mainUh oh!
There was an error while loading.Please reload this page.
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 tosuggest 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.Fixesitprojects/MasVisGtk#13
PR checklist