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

[David Abrahams]

----- Original Message -----
From: "Guido van Rossum" <guido at python.org>
To: "David Abrahams" <david.abrahams at rcn.com>
Cc: <python-list at python.org>; <python-dev at python.org>
Sent: Saturday, March 30, 2002 9:23 AM
Subject: Re: [Python-Dev] PEP 285: Adding a bool type


> > > [David Abrahams]
> > > >       6) Should we eventually remove the inheritance
relationship
> > > >          between Int and Bool?
> > > >
> > > > I hope so. Bool is-a Int doesn't seem like the right
relationship to
> > > > me, unless perhaps we make Int is-a Long... naah, not even then.
> > >
> > > Hm.  In your favorite language bool is one of the integral types.
> > > Doesn't that imply pretty much the same thing?
> >
> > Well, I try not to play favorites <0.002 wink>, but the implicit
> > conversion rules in C++ are admittedly and unfortunately liberal.
> > However, bool is detectably NOT derived from int in C++:
> >
> >     void f(int const&);
> >     f(false); // error!
> >     assert(boost::is_base_and_derived<int,bool>::value); // fails!
>
> I don't understand this example, but I though int and bool weren't
> considered classes in C++, so I'm not sure this matters.

That's correct, they're not. Still, it matters that when you do type
introspection the system doesn't tell you they're related by
inheritance. I'm sure I've written programs that would break if that
answer suddenly changed. My point is just that "int and bool are
integral types" is a very different thing from "bool is derived from
int" (for another example, derivation implies one-way implicit
conversion from derived->base, whereas the numeric types are all
implicitly inter-convertible).

> I know you
> don't care, but C99 *does* consider bool an integral type.

As does C++, and why wouldn't I care?

> Another argument for deriving bool from int: implementation
> inheritance.  A bool must behave just like an int, and this is most
> easily accomplished this way: the bool type doesn't have
> implementations for most operations: it inherits them from the int
> type, which find a bool acceptable where an int is required.

I recognize that as the /only/ real argument for such derivation. Many
are suspicious of public implementation inheritance these days, tending
to prefer delegation so as not to expose a false is-a relationship,
breaking the LSP. However, I think bool may squeeze by on that count
since as I said it's immutable. Uh, whoops, no: the repr() and str()
functions, for example change the way it works in incompatible ways.

> > > Anyway, do you have a use case where it matters?
> >
> > Given that Bool is immutable, I have no cases other than examples of
> > type introspection which can be written to account for the fact that
> > Bool is-a Int. However, it does make certain things trickier to get
> > right:
> >
> > numeric_types = [ Int, Long, Bool, Float, Complex ]
> > for t in numeric_types:
> >     if isinstance(x, t):
> >         # Do something...
> >
> > This sort of thing could depend on getting the order of the list
right
> > (I didn't).
>
> Using isinstance() this way is usually bad.

Can you say something about this that doesn't invoke a moral judgement?
I don't believe in evil programming practices, just useful/fragile ones.

> And who knows that long
> doesn't inherit from int?

In Python, people make assumptions based on their implementation because
for details like this there is often no other guideline.

> (At some point in the future it may, or
> they may become the same thing -- see PEP 237.

Well, sure, anything could happen. Anyway, I don't have a strong
position about this issue, but it rubs my instincts the wrong way.

happy-as-a-wet-cat-ly y'rs,
dave