Revert "DEP: Raise TypeError for subtract(bool_, bool_)." - #9255

I would also revert the error for negative and positive for consistency.
I also disagree on the deprecation warning, subtract on booleans is pretty clearly defined. But those have probably been there for a while so not something to revert for 1.13.1

I would also revert the error for negative and positive for consistency.

If someone reports a problem I will consider it. Note that a + (-b) != a - b.

Note that a + (-b) != a - b.

Can you elaborate on when this is true? Or are you just remarking that only one of these gives a TypeError

Also it conflicts with Python.

In [1]: False - True
Out[1]: -1

In [2]: -True
Out[2]: -1

@eric-wieser I was just remarking on the state before the deprecations where the unary - was the complement and the binary - was xor. Consistency in the ring/field Z/2 would be - does nothing, as every element is its own negative, and a - b == a+b == a^b In the case where binary + is "or" and * is "and", the customary meaning of a - b would be more like a*(~b). All of which is to argue that using ^ and ~ is more explicit than the various interpretations of -.

Also it conflicts with Python.

Perhaps then the deprecation should become a futurewarning, after which the loop becomes bool,bool->i8, which is less likely to be surprising

IIRC, we basically said that we should first make it an error a while, and then pick up that discussion @eric-wieser.

The python behavior is also pretty weird, and reflects the their history of using 0 and 1 as the bools for a long time, and then adding False and True as effectively aliases for those. (Notice issubclass(bool, int).) Numpy bools are different, and in particular are not a subtype of int in numpy's type hierarchy. One reason this is important is that bool arrays and int arrays have very different behavior in fancy indexing. (Compare python range(3)[True] vs numpy arange(3)[True].)

OK, putting this in. Might to this for 1.14 later as the deprecation cycle is just getting underway for real ;)

We could even go for the VisibleDeprecationWarning for 1.14 if we expect more problems (especially, if we expect not too uncommon usage in small scripts, etc.)

@seberg Yeah, that might be a good idea, raising a exception sure helped visibility...

Also it conflicts with Python.

Perhaps then the deprecation should become a futurewarning, after which the loop becomes bool,bool->i8, which is less likely to be surprising

This seems like a nice idea. In fact it is more informative that diff's current behavior as it indicates how something changed not just that it changed. Plus it is pretty easy to design things that will be compatible with the current and future behavior.

@jakirkham Might want to open issue, it would be more visible than this merged PR.