[Python-Dev] For review: PEP 285: Adding a bool type

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/