PREVIEW: Define the supported rcParams as code#26088
PREVIEW: Define the supported rcParams as code#26088timhoffm wants to merge 1 commit intomatplotlib:mainfrom
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.
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.
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.
Can there be comments marking each section?
|
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. |
|
Superseeded by #30871. |
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
matplotlibrcdata 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__.pyandmatplotlib.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:
rcsetupmatplotlib/lib/matplotlib/__init__.py
Lines 847 to 1189 in dbc906a
This can still be done with the current
RcParamsobject in place.This definition will likely become private and users will still use
rcParams,rcParamsDefaultetc. for the time being.