PEP 285: Adding a bool type

[Delaney, Timothy]

> From: Erno Kuusela [mailto:erno-news at erno.iki.fi]
> 
> In article <3CAA5777.66E7C2D5 at python.org>, Guido van Rossum
> <guido at python.org> writes:
> 
> | I think it's time I learn to say "yes" even if the community doesn't
> | see the light yet.

FWIW, I haven't posted a vote yet, so ...

I am very much in favour of a boolean type. I've read every single message
on the topic, and still believe that a boolean type, with True and False
would be a Good Thing(TM).

I do have a couple of issues with it though.

1. I don't know that bool should inherit from int. bool should definitely
interact with int transparently, but I feel isinstance(obj, int) and
isinstance(obj, bool) should never return true for the same object. I know
that inheriting from int is the easiest way to get the behaviour we want,
but I would prefer coercion to inheritance.

2. I think the documentation of the boolean type, and True and False
objects, should *very* strongly state that comparing to True and False is a
Bad Thing(TM) - that the values should only be used in assignment and other
appropriate places. Likewise, the tutorial will need to stress this.

3. I think it will need to be introduced with a __future__ statement as
there will be code breakage (very little perhaps, but some). This will also
give people time to get used to the idea.

> the following language changes come immediately
> to mind as feeling superfluous:
> - list comprehensions (map/filter)

I find I always use map/filter. I just don't seem to think in
comprehensions. However, *many* people use and like list comprehensions ...
so it hardly seems superfluous.

> - f(*args, **kw) (apply)

I really like this syntax, but don't get to use it much (many of my scripts
need to be 1.5.2-compatible).

The only thing added to Python since 1.5.2 that I strongly disagree with is
print >> which I consider a real wart and will never use.

And of course I'd really like built-in support for rationals :)

Tim Delaney