[Python-Dev] For review: PEP 285: Adding a bool type (original) (raw)

M.-A. Lemburg mal@lemburg.com
Sat, 09 Mar 2002 12:39:37 +0100

Guido van Rossum wrote:

> >>> True * 10 > 10 > >>> False * 10 > 0 > > If you want to dive into logic here, the only correct output > would be: > > >>> True * 10 > True > >>> False * 10 > False What has logic got to do with this?

Booleans are by nature truth values. You can do boolean algebra on them, but this algebra is completly different from what you get if you treat them as numbers having two values 0 and 1 (bits). Booleans representing a logical value should not implement +, -, *, etc. at all. Instead, they would have to be converted to integers first, to implement these operations.

I think in summary, the confusion we have run into here is caused by Python's use of bits to represent booleans. You would like to move this usage more in the direction of booleans, but only half way.

> However, this would break even more code... your bool > type is much more like a bit type (or would have to behave > like one in order to maintain backwards compatibility).

I never said otherwise. It behaves exactly like int except for those operations where the PEP specifies something different. This is intentional, since anything else will break too much code.

Exactly; which is why I don't understand the move to override str with something which doesn't have anything to do with integers :-)

Heck, it's only one method we're argueing about here. Why are all these cycles needed to convince you that backwards compatibility is better than the cosmetics of having str(True) return 'True' ? You can always implement the latter as a subtype of bool if you care enough and without breaking code.

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH

Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/