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

M.-A. Lemburg mal@lemburg.com
Wed, 03 Apr 2002 16:03:45 +0200

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 (PyTrue and PyFalse) > in Python for recognizing truth values. > > PyTrue and PyFalse 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 PyFalse is also known as &PyZeroStruct, I'm surprised that the code that optimizes ints doesn't initialize smallints[NSMALLNEGINTS] with PyFalse.

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.

> PyTrue and PyFalse 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/