On Mon, Aug 31, 2015 at 11:49 PM, Nathaniel Smith
On Sun, Aug 30, 2015 at 9:09 PM, Jaime Fernández del Río < jaime.frio@gmail.com> wrote:
There are three ways of fixing this that I see:
1. Arbitrarily choose a value to set the return to. This is equivalent to choosing a default return for `cmp` for comparisons. This preserves behavior, but feels wrong. 2. Similarly to how np.sign of a floating point array with nans returns nan for those values, return e,g, None for these cases. This is my preferred option. 3. Raise an error, along the lines of the TypeError: unorderable types that 3.x produces for some comparisons.
Having read the other replies so far -- given that no-one seems to have
any clear intuition or use cases, I guess I find option 3 somewhat tempting... it keeps our options open until someone who actually cares comes along with a use case to hone our intuition on, and is very safe in the mean time.
(This was noticed in the course of routine code cleanups, right, not an external bug report? For all we know right now, no actual user has ever even tried to apply np.sign to an object array?)
We do have a user that tried np.sign on an object array, and discovered that our Py3K object comparison was crap: https://github.com/numpy/numpy/issues/6229 No report of anyone trying np.sign on anything other than numbers that we know of, though. I'm starting to think that, given the lack of agreement, I thinking I am going to agree with you that raising an error may be the better option, because it's the least likely to break people's code if we later find we need to change it. Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.