Huh... validate_color is not tested in test_rcparams.py?

@anntzer Would it be worth to add this kind of snippet

# One would need to also import validate_color beforehand

        {'validator': validate_color,
         'success': (('None', 'none'),
                     ('none', 'none'),
                     ('AABBCC', '#AABBCC'),  # RGB hex code
                     ('AABBCC00', '#AABBCC00'),  # RGBA hex code
                     ('tab:blue', 'tab:blue'),  # named color
                     ('C0', 'C0'),  # color from cycle
                     ('(0, 1, 0)', [0.0, 1.0, 0.0]),  # RGB tuple
                     ((0, 1, 0), (0, 1, 0)),  # non-string version
                     ('(0, 1, 0, 1)', [0.0, 1.0, 0.0, 1.0]),  # RGBA tuple
                     ((0, 1, 0, 1), (0, 1, 0, 1)),  # non-string version
                     ('(0, 1, "0.5")', [0.0, 1.0, 0.5]),  # unusual but valid
                     
                    ),
         'fail': (('tab:veryblue', ValueError),  # invalid name
                  ('C123', ValueError),  # invalid RGB(A) code and cycle index
                  ('(0, 1)', ValueError),  # tuple with length < 3
                  ('(0, 1, 0, 1, 0)', ValueError),  # tuple with length > 4
                  ('(0, 1, none)', ValueError),  # cannot cast none to float
                 ),

to generate_validator_testcases in test_rcparams.py?

FWIW, currently (on Matplotlib 2.0.2) validate_color((0, 1)) or validate_color((0, 1, 0, 1, 0)) (NB: the argument is not a string here) raises an AttributeError exception because in this case (i.e. a tuple of invalid length) the validator tries to call the .find method of the argument (which does not exist for tuples). Seems like an issue to me, but I may be wrong.

I honestly care very little about the rcparam validator because, as I have already argued in many places, I think its entire design should be redone from scratch (to just use python expressions as syntax, either through eval or through a hand-written safe AST evaluator if we consider it worth it).
But you should feel free to push additional commits to this PR to enhance the tests, I won't complain either.

@anntzer I created a branch on my own fork, which first replicates your commit and second add a proper test for the validator. Unfortunately, I did not manage to understand how to push it to your branch or open a PR against it :/.

Something like

git fetch upstream pull/9038/head:pull/9038
git checkout pull/9038
# hack hack
git commit
git push

should work. Perhaps this should go to the devdocs, btw.

Thank you @anntzer, I was severely missing the first line ^^. Almost there now but it looks like I am still missing something for pushing... A simple git push yield

fatal: the current branch  pull/9038 does not have an upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin pull/9038

Of course the suggested solution just made a branch on my own fork, while replacing origin by upstream led to consequences I do not want to think about again 🐑 ...

What are these consequences? (dunno)
We may as well get how to do this clearly written in the devdocs.

I cherry-picked @afvincent 's second commit and pushed it to this branch.

BTW @anntzer, the "consequences" were that I created a new branch on the upstream Matplotlib repository :/.

Huh, seems like I let a white blank line on my initial branch on my own fork, which causes PEP8 failures. Too bad, I had it remove on the branch I created on the upstream repository ^^.

Sorry about the wrong instructions then :/

Don't be: thanks to them I already went further than I had before ;).