Mailman 3 1 + True = 2 - Python-ideas

newer
Allow __bytes__ to return...

1 + True = 2

older
Re: [Python-ideas] Exposing...

Giampaolo Rodola'

5 Jun 2016 5 Jun '16

9:37 a.m.

...

...
...
1 + True 2 1 + False 1

I bumped into this today by accident and I can't recall ever being aware of this. Why isn't this a TypeError in Python 3? -- Giampaolo - http://grodola.blogspot.com

Attachments:

attachment.htm (text/html — 543 bytes)

Show replies by date

Chris Angelico

5 Jun 5 Jun

9:48 a.m.

On Mon, Jun 6, 2016 at 2:37 AM, Giampaolo Rodola' wrote:

...

...
...
...
1 + True 2 1 + False 1

I bumped into this today by accident and I can't recall ever being aware of this. Why isn't this a TypeError in Python 3?

Because it's a good thing. bool is a subclass of int, True is exactly 1, False is exactly 0. You can sum a series of conditions and get the number that are true, for instance. There's no point doing this: sum(1 if x < 5 else 0 for x in stuff) when you can just do this: sum(x < 5 for x in stuff) to quickly count the values that fit some condition. ChrisA

Steven D'Aprano

10:23 a.m.

On Sun, Jun 05, 2016 at 06:37:48PM +0200, Giampaolo Rodola' wrote:

...

...
...
...
1 + True 2 1 + False 1

I bumped into this today by accident and I can't recall ever being aware of this. Why isn't this a TypeError in Python 3?

Because bool is a subclass of int, and has been since it was first introduced back in Python 2.2. I'm not quite sure what your question is about... are you asking what was the original justification for making True and False equal to 1 and 0? If so, see the PEP: https://www.python.org/dev/peps/pep-0285/ Or do you mean to ask why it wasn't changed in Python 3? Well, changed to what? All the reasons given in the PEP still hold, and there's no really compelling reason to make bool something else. Since bools aren't broken, why change them? -- Steve

Giampaolo Rodola'

11:37 a.m.

On Sun, Jun 5, 2016 at 7:23 PM, Steven D'Aprano wrote:

...

On Sun, Jun 05, 2016 at 06:37:48PM +0200, Giampaolo Rodola' wrote:

...
...
...
...
1 + True 2 1 + False 1

I bumped into this today by accident and I can't recall ever being aware of this. Why isn't this a TypeError in Python 3?

Because bool is a subclass of int, and has been since it was first introduced back in Python 2.2. I'm not quite sure what your question is about... are you asking what was the original justification for making True and False equal to 1 and 0? If so, see the PEP:

https://www.python.org/dev/peps/pep-0285/

Or do you mean to ask why it wasn't changed in Python 3? Well, changed to what? All the reasons given in the PEP still hold, and there's no really compelling reason to make bool something else. Since bools aren't broken, why change them?

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

Nick Coghlan

12:04 p.m.

On 5 Jun 2016 11:38, "Giampaolo Rodola'" wrote:

...

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?". The inheritance from int meant the default behaviour was to support type-promoting integer arithmetic operations in addition to bitwise arithmetic. That changes the question from "Why support that?" to "Why do the extra design, documentation and implementation work needed to prevent that?". The fact that "1 + True == 2" is surprising hasn't proven to be enough to motivate anyone to define the precise subset of operations they want to prevent, and then make the case for those restrictions as Python's native behaviour. Cheers, Nick.

Terry Reedy

6:20 p.m.

On 6/5/2016 2:37 PM, Giampaolo Rodola' wrote:

...

On Sun, Jun 5, 2016 at 7:23 PM, Steven D'Aprano mailto:steve@pearwood.info> wrote:

On Sun, Jun 05, 2016 at 06:37:48PM +0200, Giampaolo Rodola' wrote: > >>> 1 + True > 2 > >>> 1 + False > 1 > >>> > > I bumped into this today by accident and I can't recall ever being aware of > this. Why isn't this a TypeError in Python 3?

Because bool is a subclass of int, and has been since it was first introduced back in Python 2.2. I'm not quite sure what your question is about... are you asking what was the original justification for making True and False equal to 1 and 0? If so, see the PEP:

https://www.python.org/dev/peps/pep-0285/

Or do you mean to ask why it wasn't changed in Python 3? Well, changed to what? All the reasons given in the PEP still hold, and there's no really compelling reason to make bool something else. Since bools aren't broken, why change them?

I've read through the PEP and I understand the rationale about why True/False is a subclass of int

'subclass of int' means 'instances are ints'

...

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.

That is what subclass means.

...

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'

This would only be sensible if Bools were strings.

...

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,

For some people, yes.

...

in which case my question is "why?".

Just a few days ago, I read someone, while discussing an fairly large application, saying how nice python is because it allows simple code like score = sum(s==c for s, c in zip(student, correct)) (This is not the code from the application, but close enough.) There is real code in the wild exploiting issubclass(bool, int), which could be broken if that were changed. -- Terry Jan Reedy

Franklin? Lee

6 Jun 6 Jun

1:08 p.m.

On Jun 5, 2016 9:20 PM, "Terry Reedy" wrote:

...

On 6/5/2016 2:37 PM, Giampaolo Rodola' wrote:

...
On Sun, Jun 5, 2016 at 7:23 PM, Steven D'Aprano mailto:steve@pearwood.info> wrote:

On Sun, Jun 05, 2016 at 06:37:48PM +0200, Giampaolo Rodola' wrote: > >>> 1 + True > 2 > >>> 1 + False > 1 > >>> > > I bumped into this today by accident and I can't recall ever being

aware of

...

...
> this. Why isn't this a TypeError in Python 3?

Because bool is a subclass of int, and has been since it was first introduced back in Python 2.2. I'm not quite sure what your question

is

...
about... are you asking what was the original justification for

making

...
True and False equal to 1 and 0? If so, see the PEP:

https://www.python.org/dev/peps/pep-0285/

Or do you mean to ask why it wasn't changed in Python 3? Well,

changed

...
to what? All the reasons given in the PEP still hold, and there's no really compelling reason to make bool something else. Since bools

aren't

...
broken, why change them?

I've read through the PEP and I understand the rationale about why True/False is a subclass of int

'subclass of int' means 'instances are ints'

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

That is what subclass means.

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

This would only be sensible if Bools were strings.

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

For some people, yes.

...
in which case my question is "why?".

Just a few days ago, I read someone, while discussing an fairly large application, saying how nice python is because it allows simple code like

score = sum(s==c for s, c in zip(student, correct))

(This is not the code from the application, but close enough.) There is real code in the wild exploiting issubclass(bool, int), which could be broken if that were changed.

Some of that reply is too pedantic, like the part about `1+"1"`. Discuss what people are _trying_ to say, at least in addition to what they actually say. Anyway, I'd argue that, from a purity standpoint, summing an iterator of bools is hacky, and what you really want is this: # Count student answers that match the respective correct answers. count(s for s, c in zip(student, correct) if s == c) (Alas, the library for iterator operations, `itertools`, already has a very different function named `count`.) But I'm not pushing for non-int bools. Purity is not a primary Python principle. Python has `if lst:` for emptiness, and I doubt that will ever go away. (Though it makes Numpy arrays needlessly incompatible with some libraries.) Int-like bools can also be used for: - Hacky `if-else`: # Works for numbers, strs, lists, tuples, bytess, and bytearrays! (x == y)*yes + (x != y)*no - Hacky `if-else`: yes**(x == y) * no**(x != y) - Hacky `if-else`: [no, yes][x==y] - Hacky `if-else`: (x == y and [yes] or [no])[0] - Hacky `if/if-not` (control flow): (x == y) > 0 > (print("yes") or 1) (x == y) < 1 < (print("no") or 0) - Generalization of XOR: "Exactly N out of M conditions hold." * Fourth example from: https://mail.python.org/pipermail/python-dev/2002-March/020835.html Earlier discussions: - 2002 March: PEP 285 review. https://mail.python.org/pipermail/python-dev/2002-March/020750.html - 2002 March: Against int subclassing in PEP 285. https://mail.python.org/pipermail/python-list/2002-March/129054.html - 2015 January: Against int subclassing. https://mail.python.org/pipermail/python-ideas/2015-January/031233.html

Matt Ruffalo

1:07 p.m.

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

Terry Reedy

5 Jun 5 Jun

12:53 p.m.

On 6/5/2016 12:37 PM, Giampaolo Rodola' wrote:

...

...
...
...
1 + True 2 1 + False 1

I bumped into this today by accident and I can't recall ever being aware of this. Why isn't this a TypeError in Python 3?

Questions like this belong on python-list (where it has been discussed before). -- Terry Jan Reedy

2880

Age (days ago)

2881

Last active (days ago)

List overview

Download

8 comments

7 participants

participants (7)

Chris Angelico
Franklin? Lee
Giampaolo Rodola'
Matt Ruffalo
Nick Coghlan
Steven D'Aprano
Terry Reedy

1 + True = 2

tags

participants (7)