This pretty much mirrors the compromise taken in C++. However, most C++
users end up regretting the liberal implicit convertibility among the
numeric types. The latest abomination: if you want to make a new type which
can be tested in a context which demands a bool (e.g. "if (x) {...}"), what
you do is make a private dummy nested class type and give the outer type a
conversion to a pointer-to-member-function of the inner type. This allows
the expected boolean tests but prevents the object from being used in
contexts which expect actual numbers**. This ugly hack is, regrettably, "the
right thing to do" in the face of the promiscuous rules for numeric types.
-Dave
**If you're thinking, "we already have a safe way to allow new types to be
tested as booleans in Python", then you're missing the point.
----- Original Message -----
From: "Guido van Rossum"
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/)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev