PREVIEW: Define the supported rcParams as code by timhoffm · Pull Request #26088 · matplotlib/matplotlib · GitHub
Skip to content

PREVIEW: Define the supported rcParams as code - #26088

Closed
timhoffm wants to merge 1 commit into
matplotlib:mainfrom
timhoffm:config-definition
Closed

timhoffm wants to merge 1 commit into
matplotlib:mainfrom
timhoffm:config-definition

Conversation

@timhoffm

@timhoffm timhoffm commented Jun 8, 2023

Copy link
Copy Markdown
Member

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 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.

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:

  • replace matplotlibrc as source of trough
  • simplify assignment of the validators in rcsetup
  • simplify

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.

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.
@ksunden
ksunden marked this pull request as draft June 8, 2023 00:25
Comment thread lib/matplotlib/rcsetup.py
Comment on lines +1410 to +1413
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}"),

@story645 story645 Jun 8, 2023

Copy link
Copy Markdown
Member

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.

Copy link
Copy Markdown
Member Author

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.

Copy link
Copy Markdown
Member

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

@chahak13

chahak13 commented Jun 8, 2023

Copy link
Copy Markdown
Contributor

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!

@oscargus

oscargus commented Jun 8, 2023

Copy link
Copy Markdown
Member

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.

@timhoffm

timhoffm commented Jun 8, 2023

Copy link
Copy Markdown
Member Author

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?

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.

@timhoffm

Copy link
Copy Markdown
Member Author

@timhoffm timhoffm closed this Dec 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants