Skip to content

matplotlib cutsom style sheet: format dates with new line character #15813

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
blaylockbk opened this issue Dec 2, 2019 · 7 comments
Open

matplotlib cutsom style sheet: format dates with new line character #15813

blaylockbk opened this issue Dec 2, 2019 · 7 comments
Labels
status: needs comment/discussion needs consensus on next step topic: rcparams

Comments

@blaylockbk
Copy link

Bug report

Bug summary

In my custom matplotlib style sheet, I want to format the dates in such a way that includes a new line character, i.e., %b %d\n%H:%M. But matplotlib will not recognize the new line character and instead prints \n as text on my figure.

More details here: https://stackoverflow.com/questions/59144140/matplotlib-cutsom-style-sheet-format-dates-with-new-line-character?noredirect=1#comment104516325_59144140

Code for reproduction

In my my_style.mplstyle file, I have this formatting instruction for the dates (note the new line character):

    date.autoformatter.hour    : %b %d\n%H:%M

When I load the style sheet and make a plot with dates on the x axis, it displays the \n as text rather than recognizing it as a new line character.

    import matplotlib.pyplot as plt
    plt.style.use('my_style')
    import pandas as pd
    from datetime import datetime
    DATES = pd.date_range(datetime(2019, 1, 1), datetime(2019, 1, 2), 6)
    plt.plot(DATES, range(len(DATES)))

Actual outcome

image

# If applicable, paste the console output here
#
#

Expected outcome

I can get the desired outcome if I use the manual method to change the date formats directly in my code, but I would rather avoid repeating these lines of code in all my plotting scripts. That is why I want to use the style sheet to do this.

    import matplotlib.dates as mdates
    myFmt = mdates.DateFormatter('%b %d\n%H:%M')
    plt.plot(DATES, range(len(DATES)))
    plt.gca().xaxis.set_major_formatter(myFmt)

image

Matplotlib version

  • Operating system: Windows
  • Matplotlib version: 3.1.2
  • Matplotlib backend (print(matplotlib.get_backend())): module://ipykernel.pylab.backend_inline
  • Python version: 3.7.4
  • Jupyter version (if applicable):
  • Other libraries:

Installed from conda
@timhoffm
Copy link
Member

timhoffm commented Dec 2, 2019 •
edited
Loading

This is currently not possible because the parser interprets values as literal strings and thus the backslash is an actual backslash.

In [2]: plt.rcParams['date.autoformatter.hour']                                        
Out[2]: '%b %d\\n%H:%M'

One could do val.decode('unicode_escape') but that would be an API change.

We could however optionally allow string quotes date.autoformatter.hour : "%b %d\n%H:%M" and only text in quotes will be unescaped. That would keep backward-compatibility. It's also consistent with the way YAML handles strings. 😄

@timhoffm timhoffm added the status: needs comment/discussion needs consensus on next step label Dec 2, 2019
@jklymak
Copy link
Member

jklymak commented Dec 3, 2019

That proposal seems reasonable to me

@jklymak jklymak closed this as completed Dec 3, 2019
@jklymak jklymak reopened this Dec 3, 2019
@timhoffm timhoffm mentioned this issue Jan 13, 2021
Closed
@anntzer
Copy link
Contributor

anntzer commented Jan 25, 2021

We could however optionally allow string quotes date.autoformatter.hour : "%b %d\n%H:%M" and only text in quotes will be unescaped. That would keep backward-compatibility.

I don't think this keeps backcompat? I'd say the breakage is unlikely to matter in practice, but both adding support for quotes and adding support for escapes break backcompat to similar extents...

Perhaps a better solution would be to just use a different syntax to mark "new" entries, e.g.

date.formatter.hour = "..."

i.e. the equals sign (rather than colon) says that what comes after is a python literal (which we should just load using ast.literal_eval).

@timhoffm
Copy link
Member

Theoretically, it's backward compatible, but only if somebody had used string-quoting before and meaning the quotes literally. The likelyhood lf that is small, and I'd be willing to risk that. Since we will only parse escapes in quotes the breakage probability of that is ​ɛ​².

I'm not convinced of making a semantic difference with = vs. :. This is a good recipe to confuse users.

I'd also be open towards making the config YAML, which AFAICS the current config is a subset of (PyYAML has become active again for what it's worth).
I'm alternatively not completely opposed to a python config, but would need a little more convincing that's a benefit worth introducing a large incompatibility (or us maintaining two formats, respectively.

@anntzer
Copy link
Contributor

anntzer commented Jan 26, 2021 •
edited
Loading

If we choose to move to yaml (ugh) or python, the easiest is likely to just make the config files matplotlibrc.yml or matplotlibrc.py respectively, which will allow supporting both formats during the transition period without any guessing/incompatibility (and even after we drop (perhaps) support for old-style matplotlibrc, people can just keep both formats around if they want backcompat with old matplotlibs).
(I agree there's still some maintenance cost, but the python-format loader would be pretty trivial...)

@timhoffm timhoffm mentioned this issue Apr 13, 2021
Closed
@github-actions
Copy link

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!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jun 30, 2023
@QuLogic
Copy link
Member

QuLogic commented Jun 30, 2023

Quoted strings were added in #22589. @timhoffm intended to add support for backslash escapes, but it doesn't look like that has been implemented yet.

@QuLogic QuLogic removed the status: inactive Marked by the “Stale” Github Action label Jun 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: needs comment/discussion needs consensus on next step topic: rcparams
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@QuLogic @anntzer @jklymak @timhoffm @blaylockbk