PEP 285: Adding a bool type

[Stefan Schwarzer]

> I offer the following PEP for review by the community.  If it receives
> a favorable response, it will be implemented in Python 2.3.
> [...]
> Review
> 
>     Dear reviewers:
> 
>     I'm particularly interested in hearing your opinion about the
>     following three issues:
> 
>     1) Should this PEP be accepted at all.

I'm -1 on this PEP.

To summarize: The problem I have with this proposal is that it does a
half-hearted job (and can only do so because of backward compatibility
issues).

I think it's a bad deal to get

>         >>> a > b
>         True
>         >>>

but on the other hand have to keep in mind subtle interactions between
bools and ints. For example, I consider it very unintutive that
"True == 1" should by true but "True == 2" should be false. I
understand well that this is for backward compatibility, i. e. not
breaking code that uses "boolean" results to calculate something
together with numbers.

There are, as pointed out, too much cases where bool/int interactions
lead to surprises because the behaviour of the bool type does not live
up to its abstract concept that it should have. This is confusing; in
effect one would have to think _more_ whether the code does what is
should. If one deals with ints _explicitly_, calculation outcomes are
much easier to see.

Regarding special uses such as RPC and databases it would suffice to
add a "boolean" module to the standard library. This would offer a
standard way to handle a boolean type for these special purposes,
wouldn't it?

So, in my opinion the disadvantages strongly outweigh the benefits of
the PEP.

Additionally, the PEP brings some more design ambiguity which I
dislike. Should my function/method return 0, None, - or False, in a
specific case? Having to make this decision reminds me at the choice
of defining an attribute as "protected" vs. "private", or using
"virtual" or not, in C++. Sometimes, I would like to postpone
decisions until later. This thinking is in line with the earlier post
in which someone said that "it's not unusual for an integer meaning
true or false to become a 'level' variable".

_If_ the PEP is accepted (which I do not hope), I would prefer ...

>     2) Should str(True) return "True" or "1": "1" might reduce
>        backwards compatibility problems, but looks strange to me.
>        (repr(True) would always return "True".)

str(True) should be "1" (because of the arguments of Marc-Andre
Lemburg; some applications actually might make use of this
representation).

>     3) Should the constants be called 'True' and 'False'
>        (corresponding to None) or 'true' and 'false' (as in C++, Java
>        and C99).

"True" and "False"

>     Most other details of the proposal are pretty much forced by the
>     backwards compatibility requirement; e.g. True == 1 and
>     True+1 == 2 must hold, else reams of existing code would break.
> 
>     Minor additional issues:
> 
>     4) Should we strive to eliminate non-Boolean operations on bools
>        in the future, through suitable warnings, so that e.g. True+1
>        would eventually (e.g. in Python 3000 be illegal).  Personally,
>        I think we shouldn't; 28+isleap(y) seems totally reasonable to
>        me.

Not to me, despite its convenience. As the name suggests, isleap should
return a bool. But then, it shouldn't be added to an int. A solution
to resolve this would be to change the name of isleap.

>     5) Should operator.truth(x) return an int or a bool.  Tim Peters
>        believes it should return an int because it's been documented
>        as such.  I think it should return a bool; most other standard
>        predicates (e.g. issubtype()) have also been documented as
>        returning 0 or 1, and it's obvious that we want to change those
>        to return a bool.

operator.truth(x) should return a bool.

Stefan