Repository navigation
Incorrect uses of is_numlike #7795
Description
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.
As an example (not the only one), while
plt.scatter([0], [0], marker=[[0, 0], [0, 1], [1, 1]])
works as expected,
plt.scatter([0], [0], 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).
Activity
tacaswell commentedon Jan 11, 2017
Would that correctly handle a 0d (numpy-scalar) array case?
anntzer commentedon Jan 11, 2017
numpy scalars and numpy 0d arrays are not the same:
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.
jklymak commentedon Jan 18, 2018
Is this still open given #7996?
anntzer commentedon Jan 18, 2018
I would still like to ultimately replace is_numlike by isinstance(..., Number) but that needs to wait until we bump the min numpy version to 1.9.
jklymak commentedon Jan 18, 2018
Which I assume won't happen until 3.0. Feel free to bump back...
QuLogic commentedon Feb 15, 2018
Minimum version is 1.10 in
masternow, so that can be implemented now.