PEP 285: Adding a bool type

[Stefan Schwarzer]

Erik Max Francis wrote:
> Stefan Schwarzer wrote:
> > but on the other hand have to keep in mind subtle interactions between
> > bools and ints. For example, I consider it very unintutive that
> > "True == 1" should by true but "True == 2" should be false.
> 
> Why?  Implicit conversions seem un-Pythonic, so why would this be
> unfortunate?  When you write (True == 2) you're asking, "Is the value
> true equal to the integer value 2?" the answer to which is clearly no.
> Same thing with something like (2 == "2") -- no conversions are going on
> here so the test is false.

But, if I understand your argument correctly, "True == 1" and
"False == 0" shouldn't be true either because True and False are
bools, and 1 and 0 are ints. (The problem with this is, that, as a
consequence to the reasoning in the PEP, bools are ints in disguise.)

Example: "(val1, val2)[0]" is pretty clear, but "(val1, val2)[False]"
looks quite strange. If that's the price of the change I would still
prefer that "2 > 1" gives 1, not True.

So I see these choices:

1 Have a bool type without these strange interactions with ints (i. e.
  a bool should never equal an int, as an int should never equal a
  string, as you explain above), which breaks a lot of code.

2 Or, as the PEP suggests, introduce a bool type which behaves quite
  unintuitive, but keeps existing programs running.

Number 1 isn't practical, number 2 is confusing. I think it does more
harm than good.

A bool type in itself would be nice, but in fact I have never missed it
in Python. It's not worth the price which emerged during the discussion.

Stefan