It does not make the validation weaker at least.

I could make the validation stronger in the case of strings if you think it is better.

Shouldn't this be applied for all linestyles, not just grid?

👍 to@dopplershift suggestion to add this to all of the rcparams that take linestyle.

Interestingly, for negative contours, there is a commit from 2007 (4682b0c) which deprecated passing in that linestyle as a on/off pattern.

I am not sure it is exactly the same situation:

• for “normal” line styles, the non solid patterns are defined through the ad-hoc rcParams (e.g.lines.dashed_pattern), and then the rcParamlines.linestyle is expected to be a named one, in {'solid', '-', 'dashed', '--', 'dashdot', '-.', 'dotted', ':'}. Introducing the possibility to pass directly a on-off sequence seems to be doing twice the job to me :/.
• for the rcParamgrid.linestyle, the idea was to relax the validation to also accept on-off sequencesbecause we did not want to introduce the equivalent rcParams likegrid.dashed_patterns to avoid excessive granularity, but still wanted to give the possibility to use a non solid line style that is different from the “normal” ones.

By the way, I have the feeling that the deprecated validation for the negative contour line style is a bit restrictive: it seems like only 2-element sequences are accepted (i.e. [3, 1, 1, 1] would be rejected for example, if I am correct…).

Counterpoint: why on earth, from a user standpoint, is configuring grid linestyle different from the other linestyles? I get the programmer concerns, but from a UX perspective, we're giving users a new thing to learn with no justification. Feels like a set of features that grew over time (which it is) rather than a cohesive design (which is what people want).

Fair enough :), I am going to relax the validation of all the 'linestyle' rcParams, i.e.:

In [4]: [keyforkeyinplt.rcParamsifu'linestyle'inkey]Out[4]: [u'boxplot.boxprops.linestyle',u'boxplot.capprops.linestyle',u'boxplot.flierprops.linestyle',u'boxplot.meanprops.linestyle',u'boxplot.medianprops.linestyle',u'boxplot.whiskerprops.linestyle',u'contour.negative_linestyle',# beware of the existing deprecationu'grid.linestyle',u'lines.linestyle']

to accept on-off sequences.

Now all the rcParams related to a line style (butcontour.negative_linestyle) can be passed an on-off ink sequence. Besides, I added an early check that if a string is given, then it has to be one that will be accepted byLine2D.set_linestyle.

How should I handle the case ofcontour.negative_linestyle? It seems like a long time ago, one could pass an on-off ink sequence, but then is was deprecated to only accept a named line style (seevalidate_negative_linestyle_legacy inrcsetup.py). Should I deprecate the deprecation (\o/) to use the new validatorvalidate_linestyle too?If it is, what has to be done: where can I find doc on the (current) deprecation process?

Sorry, my current text editor does not yell at me when scripts are not PEP8-compliant… The other CI failure does not seem related (about “mathtext_dejavusans_21”).

I removed the former validatorsvalidate_negative_contour andvalidate_negative_contour_legacy, to now consistently rely on the new validator for all the line style-related rcParams.

There may be a (minor) break of behavior: in the new validator, I have chosen to be case-sensitive (to discourage users' jokes like “DaSHdOtTed”), while the former validator forcontour.negative_linestyle was not (theignorecase kwarg was set to True).Was this a mistake?

I'm only in favor of limiting user choice to prevent dangerous behavior/common mistakes--not silly/poor choices.

Having said that, it's much more important to me for it to be consistent with the rest of the library (like@WeatherGod said).

From what I understand, color validation is case insensitive. In_to_rgba_no_colorcycle, which is called during the process, one can read:

...# Named color.try:# This may turn c into a non-string, so we check again below.c=_colors_full_map[c.lower()]...

wherec is the “color” under test. However on the 20+ instances ofValidateInStrings, more than half of themare case sensitive.

Anyway, I guess that making_validate_linestyle case insensitive will not be dangerous and it will avoid a deprecation process to warn people that would have been using named line styles not fully in lower case for negative contours.

The new validation scheme is now private and case-insensitive :).

I have reintroduced the former validators related to thecontour.negative_linestyle rcParam, because they were part of the public API. I have nonetheless added a (lazy) deprecation warning about them. Not totally sure I followed the canonical way to do this though :/.

One last thing that bothers me a bit is that the (newly deprecated) former validatorsvalidate_negative_linestyle andvalidate_negative_linestyle_legacy do not seem bugfree (but even before this PR they were not tested, so it seems to have stayed under the radar…). See for example this traceback when (the current)validate_negative_linestyle_legacy is called with a simple 2-element list:

---------------------------------------------------------------------------AttributeErrorTraceback (mostrecentcalllast)<ipython-input-2-667b565f2256>in<module>()---->1validate_negative_linestyle_legacy([1,2])/home/adrien/matplotlib/lib/matplotlib/cbook/deprecation.pycinwrapper(*args,**kwargs)204defwrapper(*args,**kwargs):205warnings.warn(message,mplDeprecation,stacklevel=2)-->206returnfunc(*args,**kwargs)207208old_doc=textwrap.dedent(old_docor'').strip('\n')/home/adrien/matplotlib/lib/matplotlib/rcsetup.pycinvalidate_negative_linestyle_legacy(s)549defvalidate_negative_linestyle_legacy(s):550try:-->551res=validate_negative_linestyle(s)552returnres553exceptValueError:/home/adrien/matplotlib/lib/matplotlib/cbook/deprecation.pycinwrapper(*args,**kwargs)204defwrapper(*args,**kwargs):205warnings.warn(message,mplDeprecation,stacklevel=2)-->206returnfunc(*args,**kwargs)207208old_doc=textwrap.dedent(old_docor'').strip('\n')/home/adrien/matplotlib/lib/matplotlib/rcsetup.pycinvalidate_negative_linestyle(s)540"deprecation warning for more information."))541defvalidate_negative_linestyle(s):-->542return_validate_negative_linestyle(s)543544/home/adrien/matplotlib/lib/matplotlib/rcsetup.pycin__call__(self,s)64def__call__(self,s):65ifself.ignorecase:--->66s=s.lower()67ifsinself.valid:68returnself.valid[s]AttributeError:'list'objecthasnoattribute'lower'

I think it may be fixed by simply catchingAttributeErrorexception in the same way asValueError exceptions are caught invalidate_negative_linestyle_legacy.Should I do this fix too, or is it not worth it due to the deprecation?

The Travis failure seems unrelated to this PR. It is complaining abouttest_mixedsubplots inmplot3d, which has been rather flaky recently.

I'd like to understand why the deprecations are pending, and why we are deprecating for 3.0.0 (and not for 2.3). Else it looks good (I'll approve one@afvincent clarifies this point).

@NelleVWell… It simply reflects that I do not understand how the process of deprecation goes ^^…
Does “deprecated in 2.x” means
i) “This function should not be used anymore and might disappear in release 2.x + 0.2 and beyond”, or
ii) “This function might disappear at any moment since release 2.x”?
Then in case i) the deprecation should start at 2.0.1 (milestone of this PR), while in case ii) it should be 2.2 (or even later?).
For me, the current@deprecated decorators mean “We might remove this function after mpl 3 is released”, and thepending=True was used to avoid the message to beThe ... function was deprecated in version 3.0.0. ..., which sounds weird. But apparently I am wrong and they are only meaning this to my eyes, so I will be happy to change the@deprecated decorators for the version number that you prefer ;) (and I will removepending=True).

Sidenote: I think awhat's new entry might be a good thing. Unless anybody stand up against it, I will add one at the same time I will update the@deprecated decorators (likely tomorrow from this side of the Atlantic ocean).

Deprecated in 2.1 means it will be removed in 2.3.
We should not deprecate for 2.0.1 as deprecation should not happen in micro releases (but integrating the code with the warning that it is deprecated in 2.1 and removed in 2.3 is totally fine with me).

👍 on the what's new entry.

I think it is fine to push this to 2.1 (changed my mind).

Ok, the deprecations now start at 2.1. And I have added awhat's new entry. Maybe it would be wise if an native English-speaker could have a look.

PS: I have changed the PR title because actually all line style rcParams are now affected by this PR ;).

Thanks!