PEP 285: Adding a bool type: yes, but not as int subtype

[Ype Kingma]

Martin,

you wrote:
> 
> Ype Kingma <ykingma at accessforall.nl> writes:
> 
> > Python is sufficiently high level not to care about the bits.
> > Python never had a C float type, only a C double type, for precisily
> > this reason.
> 
> Python does, however, have a long int type, side-by-side with the int
> type - because it cares about bits. Atleast it used to, there is a PEP
> for merging the two integer types. There is also a PEP merging all
> numeric types into a single one, or a hierarchy of types.

I was referring to the bits in flag registers which allow all kinds of
beatiful assembly language optimizations.
I think we mostly agree here.
I'd like to know whether this PEP merging all numeric types would also merge
the bool type into its evt. hierarchy.

> 
> Notice that the relationship of bool and int has two aspects: one is
> whether you can combine them in numeric operations,
> e.g. 28+isleap(year). There is absolutely no way to remove this
> property from the language - too much code would break if that would
> raise an exception.

There are two ways to do this:
- marking such code with: from __past__ import nonbool
  (as I remarked earlier this is rather radical)
- defining __add__ and __radd__ in the int and float classes to also accept a bool
  sounds quite pythonic and acceptable to me.

> The other question is whether bool should inherit from int. Notice
> that this is unrelated: you could have the arithmetic operations even
> without inheritance. The inheritance from int is mostly an
> implementation convenience: too much code in the interpreter itself
> would need to change to make bool inherit from object only.

Agreed.
 
> > Somehow this reminds me of subclassing Square from Rectangle:
> > it just doesn't feel right, even though it might work.
> 
> I can't see the relationship: A Sqare is-a Rectangle, so following
> classic OO principles, the inheritance is clearly right. Depending on
> how you define the Rectangle interface, this inheritance relationship
> would even satisfy LSP.

An Square that is a Rectangle has inherits two degrees of freedom,
(height and width) which have to constrained to a single one in the
implementation.
Implementing such constraints is a bit awkward and can be avoided
by implementing Square as a OneDegreeOfFreedomThing and a Rectangle
as a TwoDegreeOfFreedomThing.
These ...DegreeOfFreedomThing's are intended as abstract to be consistent
with the design rule to not inherit from a class that has instantions.

When bool is-a int, one would have to (awkwardly) implement at least one
such constraint, namely that bool values can only be 1 or 0.

> > With a non int bool, True and False would be real singletons:
> >
> > bool(1) is True
> > bool(0) is False
> 
> They are singletons even under the PEP: You have to work really hard
> to make two instances of True (bool(1) is (not bool(0)) is bool(1) is
> True); and if it was a type not inheriting from int, you could *still*
> make extra instances if you wanted to hard enough.
> 
> > True is not 1
> 
> This is True in the PEP.
> 
> > True != 1
> 
> This is False, and it should be, since making it True would break
> backwards compatibility.

Ok. But just like the bool + int things above
this could be implemented by implementing __cmp__ and
__rcmp__ for the bool class and/or the numeric class.

> 
> > Subclassing bool from int would also force 1 and 0 to be become
> > real singletons.
> 
> Can you elaborate? This is not at all the case.
> 
> > The only reason this would work is that current python
> > implementations happen to implement 1 and 0 in this way.
> 
> Not at all:
> 
> >>> (1>0) is 1
> 0

You're right.

> > But you could make the language definition simpler by explicitly
> > defining the cast to bool in contexts where a boolean is expected,
> > see above. This would allow the current casts (eg. list to bool as
> > non empty) to be described at the standard types instead of in the
> > language definition.
> 
> It is already that way, the method determining truth is __nonzero__;
> for historic reasons, a number of fallbacks are taken if __nonzero__
> isn't implemented.

I guess it's time for me to reread the fine manual and to read the
bool thread on python-dev about whether the __add__ and __cmp__.

Thanks for the corrections,
Regards,

Ype