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

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > I haven't followed this thread for quite some time, but since the
> > PEP still seems alive,
> 
> :-)
> 
> > let me add some experience I've had with
> > using the already existing singletons (Py_True and Py_False)
> > in Python for recognizing truth values.
> >
> > Py_True and Py_False can be exposed in Python via
> >
> > True = (1==1)
> > False = (1!=1)
> 
> Yuck.  What a horrible implementation detail.

No really: comparisons should return booleans.
 
> > and most comparison operations and quite a few other APIs
> > returning truth values make use of these singletons.
> 
> This works purely by accident.  Given that at least Py_False is also
> known as &_Py_ZeroStruct, I'm surprised that the code that optimizes
> ints doesn't initialize small_ints[NSMALLNEGINTS] with Py_False.

Py_True and Py_False are statically allocated objects
which don't live on the heap. All the ints in small_ints
do, however.

_Py_ZeroStruct is probably just a naming inconsistency
(Py_True maps to _Py_TrueStruct).
 
> > I thought it would be a good idea to use those two
> > singletons for protocols which use booleans such as
> > XML-RPC. My experiences with this approach are, well,
> > not so good :-/
> >
> > The reason is that True and False are really integers
> > and not of a special new type. Now they are singletons,
> > which is good, since they represent the only states
> > a boolean can have and in many cases work reasonably
> > well as boolean representative, but not always
> > (e.g. arithmetic operations such as True - True == False).
> > Also, when trying to recognize the two singletons you have
> > to use the "is" comparison -- "==" will fail to
> > differentiate between 1 and True...
> >
> > def isboolean(x):
> >     return x in (True, False)
> >
> > ...doesn't work...
> >
> > def isboolean(x):
> >     return (x is True) or (x is False)
> >
> > ..does.
> 
> The correct way if PEP 285 is accepted would of course be
> isinstance(x, bool).

Let's say, that's the goal. PEP 285 is not necessarily
the complete answer to the problem ;-)
 
> > As a conclusion, I think it would be better to make bool() a
> > new type which does *not* inherit from integers, but which
> > does know how deal with other types which are commonly
> > used together with booleans such as integers. However, the
> > type should implement boolean algebra and not try to
> > mimic integer arithemtic, i.e. True - True raises an
> > exception.
> 
> That would break more code.  E.g. (a!=0) + (b!=0) + (c!=0) counts how
> many of (a, b, c) are nonzero; this would break.

Right and this is goodness, since your example is plain 
wrong if seen as boolean operation. Boolean algebra doesn't 
have +, -, *, / operations. 

The right way to write this would be:

	int(a!=0) + int(b!=0) + int(c!=0)

since you are counting values rather than finding truth
and then only if we define int(True) := 1 and 
int(False) := 0.

> > Py_True and Py_False should then be made singletons
> > of this new type (possibly after a transition phase which
> > replaces the singletons with a version that doesn't raise
> > exceptions but instead issues warnings).
> 
> That's what the PEP does (but with a different type).

Right, but my point is that if you want to make booleans
first class objects in Python, you should consider making 
them behave as defined in the text books rather than 
trying to make them feel like integers but look like
truth values.

> > This may sound painful at first, but in the long run,
> > I believe, it'll result in the same benefits as other
> > painful changes have or will (e.g. the change from integer
> > division to floating point division).
> 
> I don't see the introduction of the bool type as painful at all.
> 
> I find getting it accepted painful though. :-(

How about adding a new pure bool type to the language
*without* changing any of the old Py_False/Py_True
code (at first) ?!

Then leave the code in for one release to see how
people feel about it in real life and enable a warning
for incorrect usage of comparison arithmetic in a second 
release. The third release would then enable the new
logic per default.

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