cbook.is_numlike(obj) is implemented by checking whether obj + 1 raises. In particular, this means that numpy numeric arrays are considered as numlikes, which appears to be unintended in most cases.
obj + 1
As an example (not the only one), while
plt.scatter(, , marker=[[0, 0], [0, 1], [1, 1]])
works as expected,
plt.scatter(, , marker=np.array([[0, 0], [0, 1], [1, 1]]))
raises an exception because code in markers checks (effectively, in this case) for whether markers is "numlike", and, if so, considers it to be a number of sides for a polygon marker (at the beginning of _set_tuple_marker).
In my never-ending push to get rid of as much of cbook as possible :-), I would suggest replacing calls to is_numlike to either np.issubdtype(type(obj), np.number) (if we were using numpy>=1.9.0, this could be isinstance(obj, abc.Number)) or, if it was actually intended to accept arrays, np.issubtype(np.asarray(obj).dtype, np.number) -- we may as well distinguish explicitly between the two cases.
Edit: Actually one can just define somewhere Number = (abc.Number, np.number), then isinstance(obj, Number) will work even for older numpys (I guess).
Number = (abc.Number, np.number)
Would that correctly handle a 0d (numpy-scalar) array case?
numpy scalars and numpy 0d arrays are not the same:
n : np.float64(0), np.array(np.float64(0))
Out: (0.0, array(0.0))
Scalars pass both tests, 0d arrays only pass the second one, but I don't think we particularly need to support 0d arrays, given that you're unlikely to create them by accident.