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

[Ype Kingma]

Martin,

you wrote:
> 
> Ype Kingma <ykingma at accessforall.nl> writes:
> 
> > I'd like to know whether this PEP merging all numeric types would also merge
> > the bool type into its evt. hierarchy.
> 
> See for yourself:
> 
> http://python.sourceforge.net/peps/pep-0228.html

Quote from PEP 228:

Suggested Interface For Python's Numerical Model

    While coercion rules will remain for add-on types and classes, the
    built in type system will have exactly one Python type -- a
    number.  There are several things which can be considered "number
    methods":

    1. isnatural()
    2. isintegral()
    3. isrational()
    4. isreal()
    5. iscomplex()

End of quote.

While I wouldn't mind for bool to implement this interface,
I would object to True.isnatural() to return True, and also to
True.isintegral() to return True.

> http://python.sourceforge.net/peps/pep-0242.html

This is the one about numerical kind objects allowing
for predetermined numerical precision. Since the minimal
precision of a numerical kind from this PEP is one decimal digit
it would probably never allow for a number with only two
usable values.

> > > 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)
> 
> I hate the __future__ statement, so I definitely don't want to get a
> __past__ statement. Following PEP 5, you will need a phased
> introduction strategy for booleans if you don't want to interact them
> with numbers. Don't expect to get this in this decade, though.
> 

For backward compatibility I don't mind interacting booleans with numbers.
The coercion framework is there, it only needs to be extended with the bool class
(sigh.)

<snip>

> 
> > - defining __add__ and __radd__ in the int and float classes to also
> > accept a bool sounds quite pythonic and acceptable to me.
> 
> That would work, but only somewhat. There are other places where
> booleans need to act as integers, e.g. indexing: array[b] ought to
> work, for backwards compatibility, even if b suddently turns into a
> boolean. That means that every __getitem__ implementation needs to
> become aware of booleans - so likely a lot of code would break.
> 

Only user code __getitem__ implementations that already use booleans for
indexing would break.
When these are the only ones that would break I think deprecation
would be quite acceptable to handle them, especially because the
fix only consists of inserting an int() call.
Indexing a dict with both int and bool keys might involve some confusion
when True is not 1 anymore. This case should be rare, however.
Slices should be no problem: they only need int values, so the
evt. int() call can be provided when a slice is created.

> > 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
> 
> That depends on the rectangle interface. If rectangles are immutable,
> implementing the constraint is straight-forward, not awkward.
> 
> class Rectangle:
>   def __init__(self, x, y, w, h):
>     self.x,self.y,self.w,self.h = x,y,w,h
> 
>   def area(self):
>      return self.w*self.h
> 
> class Square(Rectangle):
>   def __init__(self, x, y, w):
>     Rectangle.__init__(self, x, y, w, w)
> 

Even in the non mutable case the redundancy of self.w and self.h
has to be accepted here.

> > 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.
> 
> Not at all. Bools are immutable, and singletons. If bool would not
> inherit from int, nothing in the implementation would change; see the
> PEP.

I meant that the implementation would need to select the appropriate
singleton instead of computing the integer as inherited in the is-a int case.

All this leaves me in favour of PEP 285 with some remarks:
- use of current booleans in user code __getitem__ implementations should
  be deprecated with indication of the int() fix. After this a bool should not be
  an int anymore.
- Once a bool is no more an int, the implementation of backward compatible 0/1 numerical
  behaviour could be done in __add__, __radd__, __cmp__, __rcmp__ and similar
  methods of the bool and/or numerical classes and in __getitem__ methods of indexable
  classes.

Regards,
Ype

P.S. Thanks for putting up with the typo's. Waking up takes more time some days.

-- 
email at xs4all.nl