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

[Alex Martelli]

On Saturday 31 March 2002 9:45, Andrew Koenig wrote:
   ...
"""
Liskov substitutibility would seem to suggest deriving int from bool,
not the other way around.  That is: If I have a program that uses bool
values, I can change it so that it uses int values without affecting
the behavior of the program.  The reverse is not true.

I wonder if this is the circle-ellipse problem over again?
"""

I think not, because circle/ellipse, square/rectangle and bag-of-bananas/
bag-of-fruit are problems only under mutability.  If an object is immutable
(either because of general language rules -- a FP language, say -- or
because of specific considerations, such as a const reference in C++) you
CAN pass a reference to an immutable circle wherever a reference to
an immutable ellipse is expected (etc) and keep Liskov happy.

And Python numbers _are_ immutable... so I don't think the problem is
related to the well-known category you mention.

Python's int and the proposed bool can't satisfy Liskov anyway, either way, 
due to str and/or repr.  If I "know" that x is one of the proposed bool 
objects, I could "assert str(x).istitle()" (or repr(x).istitle(), depending 
on which function is meant to return 'True' and 'False') -- if x is an int, 
that fails.  If I know that x is an int, I can similarly asserts 
tr(x).isdigit() -- but if x is a bool, that fails.

[Some would say this is too strict a reading of Liskov for practical use... 
do you think it is?]

Apart from str and repr issues, I cannot find any assertion I can make
under the proposed PEP, that will work for any x that is an int, but breaks
if x is a bool.  So (net of str/repr issue), any instance of bool IS-A int,
so inheriting bool from int seems OK (net of str/repr issues).  OTOH, if I 
know that x is one of the proposed bool values, I can assert 0<=x<2, and 
that will fail in many cases if x is an int instead.  So, inheriting int 
from bool seems unwarranted.  Or, am I missing something?


Alex