> But True - 1 won't equal False. Should it? No. My logic for deciding the type of "x <op> y" (and for "<op> x") is based exclusively on the types of x and y. For a given <op>, the type of "x <op> y" should be derived from the types of x and y and the properties of <op>. The values of x and y don't enter into it (except implicitly, insofar as their type limits the possible values). Thus, x&y, x|y, and x^y yield a bool when both x and y are bools, because they yield bool values whenever the arguments are both bools; but x+y is an int, even when both x and y are bools and the outcome is 0 or 1 (representable as a bool): this is because there's also a case (True+True) where the outcome (2) is not representable as a bool. The only exception is +x: this returns an int result for a bool argument. That's a matter of taste -- the unary + screams "number" to me. I could be convinced that it should return x unchanged. But in any case the type of the result still only depends on the *type* of the argument. This is a very general rule that I like a lot: that the type of a result should only depend on the type of the arguments, not on their values. I expect that this rule will make reasoning about programs (as in PsyCo or PyChecker) easier to do. I recently caved in and allowed an exception: 2**2 returns an int, but 2**-2 returns a float. This was a case of "practicality beats purity". I don't see True-1 in the same league though. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4