Repository navigation
Document that rcparam values are unquoted #3670
Description
Hi,
I'm not able to specify the default marker in matplotlibrc.
I tried:
lines.marker : '.'
lines.marker : 'point'
and others. Nothing worked.
What's the right way to do it?
Sry for asking this on the bug tracker, but I didn't now where else to ask.
Cheers
Activity
tacaswell commentedon Oct 18, 2014
What do you mean by 'not work' . Typically questions like this should go to the user mailing list (matplotlib-users@lists.sourceforge.net you have to sign up for the list to have posting rights) or stackoverflow.com .
kfiz commentedon Oct 18, 2014
By "not working" I mean, that once I test these settings by trying to plot a scatter plot, I get an error message:
"ValueError: Unrecognized marker style "." "
Next time I'll address that on the mailing list, thanks.
tacaswell commentedon Oct 18, 2014
And what version of mpl are you using?
kfiz commentedon Oct 18, 2014
In [1]: import matplotlib
In [2]: matplotlib.version
Out[2]: '1.4.0'
tacaswell commentedon Oct 18, 2014
Thanks for reporting this, this actually is a substantial bug. For some reason, when reading from the file it is growing quotes:
kfiz commentedon Oct 18, 2014
Your welcome. Thanks for the quick response.
20 remaining items
story645 commentedon Oct 2, 2016
Sorry, go ahead, totally forgot to follow up. Also what do you mean by machine shop?
github-actions commentedon Oct 9, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
story645 commentedon Oct 19, 2023
So uh finally got back to this, and I think it may make more sense to ensure that all the validation functions try to support quoted enteries rather than to document which ones do and don't. That's because, as of now, we have about 47 functions (give or take parameterizations and listifyers) for about 317 rcParams. If there's support, I'd like to repurpose the RcParams project to track work checking each function & follow up prs to add support as needed.
Basically I'm thinking the work involved is:
story645 commentedon Oct 19, 2023
Discussed on call and @ksunden pointed out that the everything string approach would create ambiguity for colors, and @QuLogic mentioned @chahak13's work may help in building a directive to improve documentation. The conclusion was that one path forward is to allow '' for the subset of validation functions that take strings where allowing quotes would not create ambiguity.
Particularly allowing for quotes in the following should handle most use cases:
timhoffm commentedon Oct 20, 2023
On a side-note: These are the burdens of having a custom file format. Any type-aware format (YAML, TOML, python files, ...) would defer these complications to the format specification/parser and set clear expectations for the user. It would in principle not be difficult do migrate to another format. The major obstacle will be argee on one of them).
story645 commentedon Oct 20, 2023
I went through all the trouble of #26854 & the like six PRs it spawned to avoid Python files 😭
But also, more seriously, I know we don't use MEPs anymore but I think the .css like approach proposed in MEP 26 would be the most natural transition from what we're already doing to a system that's more flexible and has better type support. I also think MEP 26 can be well scoped if we want to make it a paid project, either GSOC or SDG.
anntzer commentedon Nov 15, 2023
As I already suggested elsewhere, another possibility would be to keep supporting
key: value(for backcompat) but additionally supportkey = <python literal>, where all strings must be quoted (and where the literal can be parsed with ast.literal_eval), and move all the documentation to recommend the latter. This way there's no ambiguity, and I don't think asking users to quote their strings is overly painful... (plus, they can keep the old format if they want)timhoffm commentedon Nov 15, 2023
While unambiguous in definition, I'm afraid that'd be still a major source of confusion - users typically don't use this often and it's hard to remember whether it was
key: valueorkey: <python literal>.I have a strong preference for any standard format. That way we get rid of all parsing complications, and users don't have to learn a custom syntax.