[Python-ideas] 1 + True = 2

[Matt Ruffalo]

On 2016-06-05 14:37, Giampaolo Rodola' wrote:
> I've read through the PEP and I understand the rationale about why
> True/False is a subclass of int and I'm OK with that. PEP-285 at
> chapter 6 suggests a strong practical reason for this:
>
> /       In an ideal world, bool might be better implemented as a/
> /       separate integer type that knows how to perform mixed-mode/
> /       arithmetic.  However, inheriting bool from int eases the/
> /       implementation enormously (in part since all C code that calls/
> /       PyInt_Check() will continue to work -- this returns true for/
> /       subclasses of int)/
>
> What I find odd though is that a bool can be used in arithmetical
> operations as if it was the exact same thing as a number. I mean, to
> me this is just odd:
>
> >>> 1 + True
> 2
>
> I would have expected that to be treated the same as:
>
> >>> 1 + "1"
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'int' and 'str'
>
> A bool may be a subclass of int but conceptually (to me at least) it's
> different almost the same way "1" is different than 1. I say "almost"
> only because bool is a subclass of int, but then again, to my
> understanding that was done for practical reasons (implementation
> details), not because the main intention was to explicitly allow
> mixing bools and numbers in arithmetical operations. 
>
> On the other hand (and I'm gonna contradict myself with what I've just
> said above) on chapter 4:
> /
> /
> /       There's a small but vocal minority that would prefer to see/
> /       "textbook" bools that don't support arithmetic operations at/
> /       all, but most reviewers agree with me that bools should always/
> /       allow arithmetic operations./
>
> ...so maybe supporting arithmetical operations was also a primary
> intention, in which case my question is "why?".
>
> -- 
> Giampaolo - http://grodola.blogspot.com
>
When using something like NumPy or Pandas or related packages, it is
quite common and useful to compute the sum of a boolean vector to check
how many elements pass some criterion:

"""
In [1]: import numpy as np

In [2]: A = np.random.randn(25)

In [3]: A
Out[3]:
array([-1.20821997,  0.8731083 ,  0.68458201,  1.86704545,  0.67679372,
       -0.63936162, -1.2518435 , -0.55477108,  0.00940205,  1.61347396,
        1.51399244,  0.57676897,  0.86984802,  0.96965798, -0.0726013 ,
       -0.35246648,  0.12149487, -0.42062617, -0.22227402, -0.3525525 ,
       -1.04447944, -0.39717087, -0.23223961,  0.81008826,  0.34763992])

In [4]: A > 0
Out[4]:
array([False,  True,  True,  True,  True, False, False, False,  True,
        True,  True,  True,  True,  True, False, False,  True, False,
       False, False, False, False, False,  True,  True], dtype=bool)

In [5]: (A > 0).sum()
Out[5]: 13
"""

It's true that none of this behavior strictly depends on the behavior of
the Python bool object -- the behavior of NumPy arrays already diverges
quite a bit from Python lists and built-in data types, so this behavior
would probably still be part of NumPy even if arithmetic operations on
Python bools raised a TypeError. This is still a good example of why it
can be very useful to have True + True + False == 2, though.

MMR...