The circle CI failures are because the commit this is based on is older than the fix for that ( #9325 ), those can be disregarded here (or @malgamves can you rebase on to current master?)

The failure on travis is due to some trailing whitespace. The automated style checkers are a bit annoying, but the do help keep the code-base consistent, which is important for big projects with lots of contributors.

It would be better if we had a test to exercise the original issue (to make sure this really fixes it!) but this code path is covered in the tests so I am 👍 to this going in with out an extra test.

Thanks for your work on this @malgamves !

I do not think the fix is doing a right thing. In many places you can find rgbFace = mcolors.to_rgba(...) or accessing the parts of rgbFace like that

Yes, I can rebase on the current master. Lets see if that works.

I agree with @Kojoley that we should first figure out how a non-tuple made it to that point to start with (for example, it is relevant for mplcairo to know whether we can expect colorspecs to be normalized (hopefully yes) or not), and thus request a MWE from the OP of #8650.

This is the last step before we drop down to the c++ layer, I suspect that not-tuple may be the correct type for the python side and tuple is the correct type for this call.

The culprit is

Note that this is also used by draw_markers (https://github.com/matplotlib/matplotlib/blob/master/src/_backend_agg_wrapper.cpp#L254) so again we should either make sure to normalize the input early, or fix convert_rgba to accept any sequence.

(I tried to fix it quickly at the C-level but things are slightly messy because (of course...) 0-dim numpy arrays return true to PySequence_Check but trigger an error on PySequence_Size, bleh :/)

I'm going to close this - it fixes a poorly documented error, and no one else has complained. There also seems to be some petered-out concern w/ how this was implemented. Thanks @malgamves and sorry this didn't come to fruition.