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 .

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.

And what version of mpl are you using?

In [1]: import matplotlib
In [2]: matplotlib.version
Out[2]: '1.4.0'

Thanks for reporting this, this actually is a substantial bug. For some reason, when reading from the file it is growing quotes:

In [7]: matplotlib.rcParams['lines.marker']
Out[7]: u"'s'"

Your welcome. Thanks for the quick response.

@kfiz Actually, I am way over-reacting. The problem is that, contrary to all python expectations, the values in the .matplotlibrc file go in unquoted.

The correct line is

lines.marker      : .    # the default marker

I have changed your issue title to (in my view) more accurately describe the problem.

Hmm. Well specifying ".", results in "o" not ".", on my machine.
I also tried:
lines.marker : s # the default marker
Which also results in circles, i.e. "o", not squares....

That is because plot() doesn't use that parameter to determine the default
marker. It is called "lines".marker because it is specifying a default
marker for other lines like lines for polygons and such. The specification
for markers in plot() comes from the parameters to its function call. It
never checks the rcParams. Perhaps it should be better documented because
I am not exactly sure when it would apply, I just know that it doesn't
apply for plot().

By the way, single quotes are perfectly valid and are used elsewhere in the
rc file. I don't see double-quotes used anywhere in the rc file. It is an
ini-style configuration file, not a python script. Where would you put a
notice about quotations?

Ben Root

On Sat, Oct 18, 2014 at 12:26 PM, kfiz notifications@github.com wrote:

Hmm. Well specifying ".", results in "o" not ".", on my machine.
I also tried:
lines.marker : s # the default marker
Which also results in circles, i.e. "o", not squares....

—
Reply to this email directly or view it on GitHub
#3670 (comment)
.

Ok, if these settings don't apply to plot, scatter and such, then this obviously explains the behaviour I observed. I agree, one should state clearly, to what types of plots/graphics the settings in matplotlibrc apply.

lines.marker does apply to plot:

In [2]: plt.plot(range(15))
Out[4]: [<matplotlib.lines.Line2D at 0x7fcd86258790>]

with

lines.marker      : *    # the default marker

in my matplolibrc file.

The default is read in https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/lines.py#L296

Sigh... Gotta love how many levels deep we evaluate these rcParams!

I would argue that the deeper the better with these.

Now I'm really confused.
matplotlibrc:
lines.marker : * # the default marker
But:
In [2]: plot(range(15))
throws:
ValueError: Unrecognized marker style *
Is this local to my machine?

Sorry, checked again. The above example works on my machine. Had a typo in matplotlibrc.

There are no quotes in the rcparams and stylesheet docs, so can this issue be closed?

It's a bit more complicated than that. There are occasional cases of quotes such as in the cycler specification and all of the animation parameters. I suspect we are stuck with relying on the examples, as you suggest; we can't just add a line somewhere saying "don't put quotes around values in the matplotlibrc file" because there are exceptions.
@story645, would you like to have a look at the parsing code to see if you can figure out when quotes are required, optional, or forbidden?

Hi @story645
You've assigned yourself to this issue. Do you plan on moving forward with this? Else, i'll tag this issue as "machine shop" compatible.

Sorry, go ahead, totally forgot to follow up. Also what do you mean by machine shop?

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!

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:

1. choose validation method
2. find validation test method in test_rcsetup
3. add a quoted test case
4. if test case fails, add support for quoted value
5. alert maintainer to PR so we can add to project & update table

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:

• ValidateInStrings
• validate_stringlist
• validate_string

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

Any type-aware format (YAML, TOML, python files, ...)

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.

As I already suggested elsewhere, another possibility would be to keep supporting key: value (for backcompat) but additionally support key = <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)

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: value or key: <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.