-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
PREVIEW: Define the supported rcParams as code #26088
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
base: main
Are you sure you want to change the base?
Conversation
Until now, the parameter definition was dispersed: valid names and defaults are loaded from the canonical `matplotlibrc` data file. Docs are only available as comments in there. Validators are attached ad-hoc in `rcsetup.py`. This makes for a more formal definition of parameters, including meta-information, like validators, docs in a single place. It will simplify the rcParams related code in `matplotlib.__init__.py` and `matplotlib.rcsetup.py`. It will also enable us to generate sphinx documentation on the parameters.
Param("lines.dash_joinstyle", "round", validate_string, "{miter, round, bevel}"), | ||
Param("lines.dash_capstyle", "butt", validate_string, "{butt, round, projecting}"), | ||
Param("lines.solid_joinstyle", "round", validate_string, "{miter, round, bevel}"), | ||
Param("lines.solid_capstyle", "projecting", validate_string, "{butt, round, projecting}"), |
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.
This is why I'm biased towards doing type based validation - Param is of type capstyle so it gets validated by a function that lives in/as part of a capstyle type definition. That way it's consistent here and throughout the library, rather than here where you're defining the set of valid styles twice. Honestly I'd even prefer something as basic as a lines.capstyles constant that holds the set.
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 expect this to be a larger project with multiple development steps, possibly over multple PRs. As a first step here, I'm only consolidating the existing structure into a single place. Changing the validation logic at the same time would be too much.
Rethinking validation is on the plan and will become easier once this first step is taken.
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.
Can there be comments marking each section?
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.
Sure.
This is definitely useful, I think. I had a few notes on this while working on #25617 and will keep an eye on this too. Thanks! |
Is this related to the documentation of the rcParams? That is, is the "comment" a comment or a doc-string? I guess that the idea right now is to recreate the style file template? I haven't fully got my head around it, but since I think that rcParam docs is a quite crucial issues, I'm thinking if it can be added here as well? Although not hard to add at a later stage, it may be useful to be able to generate documentation for each rcParam. |
For now (step 1) it's only to recreate the template. I plan to add the possibility for proper documentation later, which then can also be extracted into sphinx pages. |
Disclaimer: This is very much work in progress and may substantially change before sent to review. But I want to give interested folks the opportunity to already have an early look.
Motivation
Until now, the parameter definition was dispersed: valid names and defaults are loaded from the canonical
matplotlibrc
data file. Docs are only available as comments in there. Validators are attached ad-hoc inrcsetup.py
.This makes for a more formal definition of parameters, including meta-information, like validators, docs in a single place. It will simplify the rcParams related code in
matplotlib.__init__.py
andmatplotlib.rcsetup.py
. It will also enable us to generate sphinx documentation on the parameters.Related: #23531, #4394
Scope / context
This can be seen in the context of the larger idea of re-designing the config system. However, for now the direct goal is to:
rcsetup
matplotlib/lib/matplotlib/__init__.py
Lines 847 to 1189 in dbc906a
This can still be done with the current
RcParams
object in place.This definition will likely become private and users will still use
rcParams
,rcParamsDefault
etc. for the time being.