Cannot set drawstyle default to 'steps-post' in 3.0.0
In 2.0.2 I could set the default drawstyle by settings rcParams['lines.linestyle']. In 3.0.0, it barfs.
Is there a different way to set this? I don't see any rcParams keys that reference drawstyle or look like they could be impacting drawstyle
Code for reproduction
Python 3.5.4 |Continuum Analytics, Inc.| (default, Aug 14 2017, 13:26:58)
Type 'copyright', 'credits' or 'license' for more information
IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import matplotlib
In [2]: matplotlib.__version__
Out[2]: '2.0.2'
In [3]: matplotlib.rcParams['lines.linestyle'] = 'steps-post'
In [4]: print(matplotlib.get_backend())
Qt5Agg
In 3.0.0, this happens
Python 3.6.6 |Anaconda, Inc.| (default, Jun 28 2018, 17:14:51)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import matplotlib
In [2]: matplotlib.__version__
Out[2]: '3.0.0'
In [3]: matplotlib.rcParams['lines.linestyle'] = 'steps-post'
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
~/.conda/envs/bamboo/lib/python3.6/site-packages/matplotlib/__init__.py in __setitem__(self, key, val)
860 try:
--> 861 cval = self.validate[key](val)
862 except ValueError as ve:
~/.conda/envs/bamboo/lib/python3.6/site-packages/matplotlib/rcsetup.py in _validate_linestyle(ls)
949 if isinstance(ls, (str, bytes, bytearray)):
--> 950 return _validate_named_linestyle(ls)
951
~/.conda/envs/bamboo/lib/python3.6/site-packages/matplotlib/rcsetup.py in __call__(self, s)
64 raise ValueError('Unrecognized %s string %r: valid strings are %s'
---> 65 % (self.key, s, list(self.valid.values())))
66
ValueError: Unrecognized linestyle string 'steps-post': valid strings are ['-', '--', '-.', ':', 'solid', 'dashed', 'dashdot', 'dotted', 'none', ' ', '']
During handling of the above exception, another exception occurred:
ValueError Traceback (most recent call last)
<ipython-input-3-7f838b7219da> in <module>
----> 1 matplotlib.rcParams['lines.linestyle'] = 'steps-post'
~/.conda/envs/bamboo/lib/python3.6/site-packages/matplotlib/__init__.py in __setitem__(self, key, val)
861 cval = self.validate[key](val)
862 except ValueError as ve:
--> 863 raise ValueError("Key %s: %s" % (key, str(ve)))
864 dict.__setitem__(self, key, cval)
865 except KeyError:
ValueError: Key lines.linestyle: Unrecognized linestyle string 'steps-post': valid strings are ['-', '--', '-.', ':', 'solid', 'dashed', 'dashdot', 'dotted', 'none', ' ', '']
In [4]: print(matplotlib.get_backend())
Qt5Agg
That's been the case since #8040 (2.1.0) and I don't have anything to do with that :)
I do have #12442 to further separate drawstyles from linestyles (see also #11797 for the mess that linestyles currently are), but that's not even merged yet.
I think I remember @ImportanceOfBeingErnest suggesting somewhere to create a separate rcParam for drawstyle(?).
#11797 concerns the linestyle. In addition I mentionned in #12493 about adding hist.histtype
plus 1 on adding the rcParameter. Equally, a lines.drawstyle rcParams would be useful.
I wasn't aware that step... could be used as lines.linestyle. This seems the wrong place for it and I strongly believe that step... should not be an allowed linestyle. Not sure what to do about this apparently being a regression though.
Yes, you do have a point, but it would be quite useful in practice.
In our use case, we're integrating Matplotlib into a simulator, for result analysis purposes.
The data series we'd like to plot can indeed have different properties, and therefore should be plotted differently. Being able to simply switch between "no lines", "linear interpolation" (what .plot() does), and the three steps- modes with a single variable, without having to add logic for switching between .plot() and .steps() would be nice.
Also, there might have been a good reason why lines.linestyle supported it, even if it wasn't the appropriate key for it.
Based on the discussion above and the lack of activity for years, I am going to claim that not supporting drawstyles in lines.linestyle is intentional (I still don't think it should be supported). If someone wants to put up a PR for adding lines.drawstyle this could be discussed with the PR.
Activity
tacaswell commented on Oct 21, 2018
attn @anntzer Did we change this intentionally?
anntzer commented on Oct 21, 2018
That's been the case since #8040 (2.1.0) and I don't have anything to do with that :)
I do have #12442 to further separate drawstyles from linestyles (see also #11797 for the mess that linestyles currently are), but that's not even merged yet.
I think I remember @ImportanceOfBeingErnest suggesting somewhere to create a separate rcParam for drawstyle(?).
tacaswell commented on Oct 21, 2018
Ah, I miss read the version @tsdlovell was starting with (sorry!)
I must have remembered seeing #12442 .
ImportanceOfBeingErnest commented on Oct 21, 2018
#11797 concerns the linestyle. In addition I mentionned in #12493 about adding hist.histtype
I wasn't aware that step... could be used as lines.linestyle. This seems the wrong place for it and I strongly believe that step... should not be an allowed linestyle. Not sure what to do about this apparently being a regression though.
torokati44 commented on Jan 21, 2020
Yes, we would also appreciate a lines.drawstyle key in rcParams.
timhoffm commented on Jan 21, 2020
I'm not even sure, that should be a rc parameter. Steps is not a style but a fundamental change to the meaning of lines.
For your purposes, is it an option to use step() for plotting? That makes the intention more explicit.
torokati44 commented on Jan 22, 2020
Yes, you do have a point, but it would be quite useful in practice.
In our use case, we're integrating Matplotlib into a simulator, for result analysis purposes.
The data series we'd like to plot can indeed have different properties, and therefore should be plotted differently. Being able to simply switch between "no lines", "linear interpolation" (what .plot() does), and the three steps- modes with a single variable, without having to add logic for switching between .plot() and .steps() would be nice.
Also, there might have been a good reason why lines.linestyle supported it, even if it wasn't the appropriate key for it.
anntzer commented on Aug 20, 2024
Based on the discussion above and the lack of activity for years, I am going to claim that not supporting drawstyles in lines.linestyle is intentional (I still don't think it should be supported). If someone wants to put up a PR for adding lines.drawstyle this could be discussed with the PR.