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...