matplotlibrc reader cannot handle rcparams with a hash

The parser for the .mplstyle files is eager when identifying comments. A # always demarcates the beginning of a comment, therefore it cannot be part of an rcparam.

Reference: #6907 (comment)
The reader function: https://github.com/matplotlib/matplotlib/blob/af16ac8/lib/matplotlib/__init__.py#L1055
Example style file: https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/mpl-data/stylelib/classic.mplstyle#L183

Maybe we should just use json or yaml for the style files?

not json... and yaml brings in another dependency (but it isn't that
onoerous...). ConfigParser is now in the standard library, and it could
bring for us string interpolation features (which I have been wanting for a
while).

On Sun, Sep 11, 2016 at 12:02 PM, Thomas A Caswell <notifications@github.com

wrote:

Maybe we should just use json or yaml for the style files?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7089 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-OJk5Y42-PwB0UT6oMQeDlYXQc57ks5qpCYigaJpZM4J57mm
.

Comparison of potential options.

	YAML	JSON	ConfigParser
No Extra Dependency	No	Yes	Yes
Interpolation	Yes	No	Yes
Inline comments	Yes	No	Yes[1]

Caveats

Cannot be used for entries that have only keys(and no values).

It doesn't look to me like ConfigParser provides facilities for gracefully handling the problem of an inline hash that starts a comment unless it is inside a string. YAML looks like a pretty big hammer. I think I would rather leave the existing restriction against having the hash in a value than introduce a new dependency and a new set of rules for matplotlibrc and style files.

JSON can not support inline comments

On Sun, Sep 11, 2016 at 2:07 PM, Eric Firing notifications@github.com
wrote:

It doesn't look to me like ConfigParser provides facilities for gracefully
handling the problem of an inline hash that starts a comment unless it is
inside a string. YAML looks like a pretty big hammer. I think I would
rather leave the existing restriction against having the hash in a value
than introduce a new dependency and a new set of rules for matplotlibrc and
style files.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7089 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-Jww4rIys61x5noWIlfmpVh-C0PNks5qpENbgaJpZM4J57mm
.

I'm going to make a possibly not so popular but actually serious proposal: if we do decide to change the config format, simply switch to using python source files as style and config formats.

Pros:
No extra dependency, interpolation, inline comments (duh).
Basically anything you will ever need.

Cons:
AFAICT the main con I have heard about is the security issue. But the current parser is already unsafe (See link from OP in #6274 (Yes, I know that PR also proposes a custom PyParsing-based parser -- I guess that would be a pretty big hammer...)). Additionally, a number of prominent projects (e.g. IPython, Sphinx, Django) already use python for config files without this turning out to be a real problem.

This should also be coordinated with the traitlets work #4762 Afaik the IPython config files are traitlets based

Why not just make yaml an optional parser for the matplotlibrc reader, if installed? The amount of code to read into the rc system is minimal, and we could integrate them more closely over time if needed.

I've already made a basic parser for this type of data for use in a project, it seems to work fine for basic datasets:

with open(fn) as f:
    style_object = yaml.load(f)
for k,v in style_object.items():
    matplotlib.rc(k,**v)

...which reads YAML configuration files as below into matplotlibrc.

font:
  size: 8
  family: [sans-serif]
  sans-serif:
    - Helvetica Neue
    - Helvetica
    - Arial
    - sans-serif
  weight: 200
mathtext:
  default: regular
axes:
  labelsize: 8
  titlesize: 12
  facecolor: white
  grid: false
  edgecolor: black

A more bulletproof parser would probably take some effort, but I imagine not much. Happy to submit a pr if it seems like a good plan.

My personal opinion is that yaml is a far too complex language for any purpose (see e.g. http://stackoverflow.com/questions/3790454/in-yaml-how-do-i-break-a-string-over-multiple-lines).

and why is having multiple ways to do a multi-line string a bad thing? There are a few things I don't like about YAML, but that isn't one of them.

…

On Sat, Apr 15, 2017 at 5:54 PM, Antony Lee ***@***.***> wrote: My personal opinion is that yaml is a far too complex language for any purpose (see e.g. http://stackoverflow.com/questions/3790454/in-yaml-how- do-i-break-a-string-over-multiple-lines). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7089 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARy-HqhfLaHMvLMjbW9ALmS8J0meiffks5rwTypgaJpZM4J57mm> .

This is just an example amongst others of the extreme complexity of the language. For example, would you know whether

- % foo

is valid yaml? if so, what does it evaluate to? what about

- foo % foo

?

@anntzer

YAML is a pretty standard config language for many projects, and trying to reinvent the wheel when a standard tool can be adapted to the system is unnecessary.

@anntzer: we don't have to support the entire feature-set of YAML or handle edge cases for it to be useful nonetheless

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!

In #22589 support for quoted strings was introduced, which then allows including a hash. Will close this for now.

Navigation Menu

Repository navigation

matplotlibrc reader cannot handle rcparams with a hash #7089

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

matplotlibrc reader cannot handle rcparams with a hash #7089

Description

Activity

tacaswell commented on Sep 11, 2016

WeatherGod commented on Sep 11, 2016

has2k1 commented on Sep 11, 2016

efiring commented on Sep 11, 2016

WeatherGod commented on Sep 11, 2016

anntzer commented on Sep 12, 2016

jenshnielsen commented on Sep 12, 2016

davenquinn commented on Apr 15, 2017

anntzer commented on Apr 15, 2017

WeatherGod commented on Apr 16, 2017

anntzer commented on Apr 16, 2017

davenquinn commented on Apr 16, 2017

github-actions commented on Mar 29, 2023

oscargus commented on Apr 7, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions