Fix cycler validation #6275
Fix cycler validation #6275
Conversation
|
@WeatherGod Why is there an extra merge commit in here? |
| @@ -767,6 +759,17 @@ def validate_cycler(s): | |||
| else: | |||
| raise ValueError("object was not a string or Cycler instance: %s" % s) | |||
|
|
|||
| unknowns = cycler_inst.keys - (set(_prop_validators.keys()) | | |||
There was a problem hiding this comment.
You do not need the keys as iterating over a dict gives the keys anyway.
|
👍 on doing the normalization here. I suspect that this will not catch everything as aliases will still fall through the plot functions in funny ways. |
* Allow key normalization to Cycler objects * Validation is performed at more entry points * Requires Cycler v0.9+
|
This isn't meant to catch anything having to do with plotting functions. This is strictly about the problem arising from having multiple entry points from which users can supply a property cycler, and normalizing the aliases was only done at one of the entry points. Now, aliasing will happen at every entry point. We are still left with validation only happening if the cycler is passed as a string, but full validation will need the newer cycler features. |
|
The extra merge commit seemed to have happened because I originally forked from the v1.5.x branch, but submitted this as against master instead. I'll fix that at the next batch of updates to this PR. |
|
I mean that users can pass |
|
That is the responsibility of the individual plotting functions. The plotting functions can now assume that the property cycle will always have the normalized property names. Previously, it was possible that it didn't always have that, and as such, would do a double-update. That is now fixed. However, you can also get a double-update if the plotting function does not properly normalize its list of properties before consulting the property cycle. We are much better about this than we used to be, but still not perfect. |
|
I think we are on the same page. |
|
Of course, there is still the fun aspect of fall-back properties (e.g., using color when facecolor or linecolor isn't provided), and the weird mixing of terminology (e.g., eliding 'color' to mean 'facecolor' in bar()). |
WeatherGod
force-pushed
the
fix_cycler_validation
branch
from
494531e
to
2128c96
Compare
|
Please note, I accidentally pushed up this branch to matplotlib's repo. I deleted that branch, and cancelled the extra travis build that it triggered (comes up now as an error). I don't think I have any permissions to cancel the extra appveyor build, though. |
|
I just noticed that this is milestoned for v1.5.2. That might need to be reconsidered because of the version bump in the cycler dependency? Not that it is a difficult dependency, I just didn't know if we should do that in a bugfix release. Also, it isn't like what I am fixing is a regression, since property cyclers were brand-new in v1.5. |
tacaswell
modified the milestones:
2.0 (style change major release),
1.5.2 (Critical bug fix release)
|
I am sold on not bumping the version of required cycler on 1.5.x branch. |
|
cycling this PR didn't get rid of the bad Appveyor/Travis runs that happened when I accidentally pushed to the repo. So they should be ignored. The PR test runs are green. |
|
backported to v2.x as 337fb07 |
This should fix the cycler normalization/validation bugs we have seen such as #5875. This does require a minimum version of Cycler v0.9 to get the
change_key()feature. We could go a few steps further and get full validation of property values for Cycler objects, but that will require Cycler v0.10, I think, so that I can introspect the cycler object better -- not out of the question, but I figure I would get this first step done first.