PEP 285: Adding a bool type

[Mark 'Kamikaze' Hughes]

Sat, 30 Mar 2002 00:39:10 -0500, Guido van Rossum <guido at python.org> spake:
> PEP: 285
> Title: Adding a bool type
>     1) Should this PEP be accepted at all.

  Excellent - I have TRUE and FALSE defined in most of my Python code
for exactly this reason, and I'd much rather have a system-defined pair
of constants with some language support instead.

>     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 "True", str(False) should be "False" - the main
annoyance I had with enumerated types in C was that they printed as
ints, not as their names.  What bloody good was that?

  Backwards compatibility is a problem, though.  You may want to have an
optional warning in 2.3 - str(bool) will be difficult to find with just
a grep, you need to examine every line of the code, or test it at
runtime.

  If everyone had comprehensive unit tests, they wouldn't have this
problem, but that's not often the case.

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

  While I'm more comfortable typing true and false from Java programming
habits or TRUE and FALSE from old C habits, True and False are more
consistent with Python's style, and you should use those.

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

  The central problem with that is that Python doesn't have a ternary
operator, which means that Python programmers use math on booleans more
than usual.  I don't see a problem with this, anyway, as long as people
know what the int values of True and False are.

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

  truth() should return a bool, and the documentation should be changed,
to make the current use of 0 and 1 implicitly meaning false and true
explicit.

>     It has been suggested that, in order to satisfy user expectations,
>     for every x that is considered true in a Boolean context, the
>     expression x == True should be true, and likewise if x is
>     considered false, x == False should be true.  This is of course
>     impossible; it would mean that e.g. 6 == True and 7 == True, from
>     which one could infer 6 == 7.  Similarly, [] == False == None
>     would be true, and one could infer [] == None, which is not the
>     case.

  It's also not necessary - bool(6) == bool(7) is the expression being
reached for there, and it works just fine.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"No one is safe.  We will print no letters to the editor.  We will give no
space to opposing points of view.  They are wrong.  The Underground Grammarian
is at war and will give the enemy nothing but battle." -TUG, v1n1