breaking change in dash verification in 2.0.0

This no longer works:

import matplotlib.pyplot as plt
from cycler import cycler
plt.rc('axes', prop_cycle=(
    cycler('dashes', [(None, None), (None, None), (6, 6), (3, 3), (1.5, 1.5)])))

but it used to work in 1.5.

Now it yields

TypeError: float() argument must be a string or a number, not 'NoneType'

I would appreciate a work-around, too. The intention is that the first two lines are solid, and then we get dashes.

Using a small positive number is a decent workaround for me for now:

import matplotlib.pyplot as plt
from cycler import cycler
% matplotlib inline
import numpy as np

plt.rc('axes', prop_cycle=(cycler('dashes',
                                  [(1, 0.01), (1, 0.01), (6, 6), (3, 3), (1.5, 1.5)])))

for i in range(5):
    plt.plot(np.sin(np.linspace(-5, 5, 100) + i))

In case anyone wonders wtf I'm doing here: In b/w, I feel like we can distinguish two solid lines by color, but for more than two lines I want dash-patterns.

@amueller

An alternative workaround may be to use the plot kwarg linestyle (or ls) instead of the dashes one. One can then use named line styles ('solid' or '-' for example), or (offset, on-off ink sequence). It is a bit more verbose but the following script seems to be working properly on master

import matplotlib.pyplot as plt
from cycler import cycler
import numpy as np

plt.rc('axes', prop_cycle=(cycler('linestyle', ['-', '-', (0, (6, 6)),
                                                (0, (3, 3)), (0, (1.5, 1.5))]))
       )

for i in range(10):
    plt.plot(np.sin(np.linspace(-5, 5, 100) + i))

PS : @amueller is it normal that there are 6 lines on your picture while plt.plot is only called 5 times in your example script?

I changed the script but then didn't reupload the picture ;)

Thanks for your suggestion. That seems cleaner.

The issue still has to be fixed but at least this workaround should avoid using (1, 0.01) dashes when the meaning is "a solid line please" ;).

Was just looking through the Issues page for fun and decided to try my hand at fixing this.

Ran the code from the OP using different versions of 1.5.x and 2.0.x and this is definitely only a bug that exists in 2.0.x. So I ran the code through pdb and found that it was failing on line 316 in validate_nseq_float() of rcsetup.py. A quick looks through the 1.5.x codebase shows that validate_nseq_float() exists there so it's not the original cause of this bug.

Some more diving with pdb and I found that validate_nseq_float() was being called on the cycler() input in OP on line 861 of rcsetup.py in validate_cycler(). This line was calling the _prop_validators dictionary using "dashes" as the key and the list of five tuples as the vals which came from the OP code. The "dashes" entry in the _prop_validators dict corresponds to the validate_dashlist callable on line 698 which is a listified version of validate_nseq_float(). Looking through the 1.5.x code again it seems that this extra cycle "dashlist" validation code doesn't exist there so it seems to be the reason that the OP code is failing. Checking git blame on line 698 I find that this extra validation code comes from commit 9ee5f8d which landed in 2.0.x.

validate_nseq_float(s) checks that the given finite sequence s contains only floats but looking at the documentation for dashes, (None, None) is valid input so using a float-only validator is a regression. Then the solution to this bug seems to be either:

Change validate_nseq_float to allow Nones which I have done in dkua@353aceb
Add an additional validator for finite sequences of floats and Nones which I have done as validate_nseq_float_or_None in dkua@72120b3 and dkua@7916b3a

I've tested both of those options manually on my computer using the OP code and they both produce a correct looking plot without crashing as in 1.5.x. I can add in a quick test and submit one of the options as a PR for this issue but have not decided which option is better and want to ask the matplotlib team first. The first option seems suboptimal since validate_nseq_float() is used elsewhere in the code but the second option adds in extra near-duplicate code. Either option it seems the int equivalent of these validators should also be changed since this might come up for them later on too (maybe?).

Please let me know what y'all think.

Fixes matplotlib#8141

I've submitted a PR that should fix this issue by allowing None values only when validating dashed line styles via validate_nseq_float with a new allow_none flag flipped on, while retaining the original behaviour for other validators using validate_nseq_float to avoid any breaking changes.

Adding another validator just for dashed lines seems redundant, IMO.

Fixes matplotlib#8141

Merge pull request #8196 from kenmaca/pr-dash-verification-8141

Fixes matplotlib#8141

Merge pull request #1 from kenmaca/pr-dash-verification-8141

update (#7)

Merge pull request matplotlib#8196 from kenmaca/pr-dash-verification-…

Navigation Menu

breaking change in dash verification in 2.0.0 #8141

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

breaking change in dash verification in 2.0.0 #8141

Description

Activity

amueller commented on Feb 24, 2017

amueller commented on Feb 24, 2017

afvincent commented on Feb 24, 2017

amueller commented on Feb 24, 2017

amueller commented on Feb 24, 2017

afvincent commented on Feb 24, 2017

dkua commented on Mar 2, 2017

kenmaca commented on Mar 5, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions