On Thu, Apr 07, 2016 at 11:08:38AM -0700, Guido van Rossum wrote:
To be more precise, there are some "arithmetic" operations (+, -, *, /, **) and they all treat bools as ints and always return ints; there are also some "bitwise" operations (&, |, ^, ~) and they should all treat bools as bools and return a bool.
You missed two: >> and <<. What are we to do with (True << 1)? Honestly, I cannot even imagine what it means to say "shift a truth value N bits". I think the idea that bitwise operations on bools are actually boolean operations in disguise is not a well-formed idea. Sometimes it happens to work out (& | ^), and sometimes it doesn't (<< and ~). And I'm not sure what to make of >> as an operation on bools. It doesn't *mean* anything, you can't shift a truth value, the very concept is meaningless, but if it did mean something it would surely return False. So >> could go into either category. But ultimately, ~ has meant bitwise-not for 25 years, and it's never caused a problem before, not back in the days when people used to write TRUE, FALSE = 1, 0 and not now. If you want to perform a boolean "not" on a truth value, you use `not`. Nobody cared enough to "fix" this (if it is a problem that needs fixing, which I doubt) when bools were first introduced, and nobody cared when Python 3 came out. So why are we talking about rushing a backwards- incompatible semantic change into a point release? Even if we "fix" this, surely we should go through the usual deprecation process? This isn't a critical security bug that needs fixing, it's a semantic change to something that has worked this way for 25 years, and its going to break something somewhere. There are just far too many people that expect that bools are ints. After all, not withstanding their fancy string representation, they behave like ints and actually are ints. -- Steve