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

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> [MAL]
> > > > If you want to dive into logic here, the only correct output
> > > > would be:
> > > >
> > > > >>> True * 10
> > > > True
> > > > >>> False * 10
> > > > False
> 
> [Guido]
> > > What has logic got to do with this?
> 
> [MAL]
> > 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.
> 
> So you're reversing your position.  First (see above) you were
> pleading that True*10 should yield True.  Now you are pleading that it
> should raise an exception.

No, I'm just giving evidence of what mixing booleans with
bits can lead to.
 
> Anyway, in a brand new language the latter might be a good idea, but
> since we're trying to evolve Python without breaking (much) existing
> code, we have no choice: bools must behave like ints as much as
> possible, especially in arithmetic.

Right, but please don't try to add some booleaness to bits.
 
> > I think in summary, the confusion we have run into here is
> > caused by Python's use of bits to represent booleans.
> 
> I don't understand this.  The way I see it, current Python doesn't use
> bits for Booleans.  It has no Boolean type, and the integers 0 and 1
> are conventional but not the only ways to spell Boolean outcomes.

Bits are 1 and 0. Booleans are True and False. You can coerce
the two mathematical types, but they essentially cover different
areas, e.g. 

>>> True - True
False

simply doesn't fly.
 
> > You would like to move this usage more in the direction of booleans,
> > but only half way.
> 
> Yes, forced by backwards compatibility.
>
> > Exactly; which is why I don't understand the move to
> > override __str__ with something which doesn't have anything
> > to do with integers :-)
> 
> Probably because we have a different intuition on how str() is used.
> For me, it's mostly used as an output conversion.  But it seems that
> for you, conversion to a decimal int is important because you need to
> feed that into other applications that require decimal strings.

Right.
 
> > 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' ?
> 
> Maybe because at the start it wasn't clear that that is your only
> *real* objection, and you brought so many other arguments into play?

You started this game and asked for these many arguments :-)

My only objection is overriding the __str__ method. Everything
else is just fine.

You don't have a boolean type in the sense of algebra, but we 
can't change that due to Python's history and a true algebraic 
boolean type can easily be written as extension, so it doesn't
worry me much.

Hmm, perhaps you should name the type "truth" or "truthvalue" 
rather than boolean.

> Or maybe because you and I are using Python in very different ways, so
> that what's obvious for you isn't always obvious for me (and vice
> versa)?

Could be... I don't like it when things are broken on purpose
just to have an interactive session return "nice" output. I also
don't like scanning tons of code to find the few instances
where this change breaks application interop.

There must be other ways to satisfy your requirements and
mine.

> > You can always implement the latter as a subtype of bool if you care
> > enough and without breaking code.
> 
> I thought about this last night, and realized that you shouldn't be
> allowed to subclass bool at all!  A subclass would only be useful when
> it has instances, but the mere existance of an instance of a subclass
> of bool would break the invariant that True and False are the only
> instances of bool!  (An instance of a subclass of C is also an
> instance of C.)  I think it's important not to provide a backdoor to
> create additional bool instances, so I think bool should not be
> subclassable.
> 
> Of course, you can define your own subclass of int similar to the bool
> class I show in the PEP, and you can give it any semantics you want --
> but that would also defeat the purpose of having a standard bool.
> 
> What will happen in reality is that people will have to write:
> 
>     print repr(b)
> 
> rather than:
> 
>     print b
>
> That's not terribly bad.  But I'm not sure I'm ready to answer the
> complaints from newbies who are confused by this:
> 
>     >>> isinstance(1, int)
>     True
>     >>> print isinstance(1, int)
>     1
>     >>>

This is not different from printing other objects:

>>> from mx.DateTime import *
>>> now()
<DateTime object for '2002-03-09 18:32:10.21' at 82424b8>
>>> print now()
2002-03-09 18:32:12.93

or

>>> 1.4
1.3999999999999999
>>> print 1.4
1.4

> So I need someone else to chime in with additional evidence that
> str(True) should be '1', not 'True'.  So far you've been carrying this
> particular argument all by yourself.

I was also the only one that had objections when nested scopes 
were first proposed by Jeremy on this list... I'm sure others
will chime in once you have checked in an implementation.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/