PEP 285: Adding a bool type

[Justin Sheehy]

Guido van Rossum <guido at python.org> writes:

>     1) Should this PEP be accepted at all.

-0

I don't think it is needed, and I think that the negative aspects
(most of which were well-put by Alex Martelli) are as significant as
the positive ones.

Assuming that it does go through as exists:

>     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".)

"True"

>     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'

>     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.

No.  If pure boolean values had been in the language from very early
on, then it would make sense to have them break when used in
arithmetic.  Since people have written much code that relies on the
integerness of booleans, and it remains convenient to do so, it should
remain allowed.

>     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.

int, though I don't think it matters much.

-Justin