[Python-Dev] Re: PEP 285: Adding a bool type

[Christian Tanzer]

>    1) Should this PEP be accepted at all.

I can do without it, but wouldn't mind it, as long as bools don't get
too strict (like point 4, below). IMHO, Python's traditional concept
of truth is much better than a Pascal-like concept of truth.

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

If str and repr were to behave differently from each other, I'd expect
repr(True) to return "1" and str(True) to return "True". Interchanging
that seems strange.

OTOH, I'm worried about backwards compatibility.

>     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', please. It makes shadowing of the built-in values
by user defined variables much less likely.

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

IMHO, `28+isleap(y)` is certainly better than `28+int(isleap(y))`.

Used judiciously, booleans in arithmetic expressions can improve
readability over conditional statements.

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

I'd expect operator.truth to be an alias for 'bool'.

If booleans couldn't be used in integer contexts any more, I'd prefer
operator.truth to return an int <wink>.

>     Because of backwards compatibility, the bool type lacks many
>     properties that some would like to see.  For example, arithmetic
>     operations with one or two bool arguments is allowed, treating
>     False as 0 and True as 1.  Also, a bool may be used as a sequence
>     index.

Counting the number of true values in a collection is a common
operation. Using bool as an index is also commonly needed.

IMO, allowing booleans in these contexts is a good thing (TM) in
general, not only for backwards compatibility.

>     Other languages (C99, C++, Java) name the constants "false" and
>     "true", in all lowercase.  In Python, I prefer to stick with the
>     example set by the existing built-in constants, which all use
>     CapitalizedWords: None, Ellipsis, NotImplemented (as well as all
>     built-in exceptions).  Python's built-in module uses all lowercase
>     for functions and types only.  But I'm willing to consider the
>     lowercase alternatives if enough people think it looks better.

Please make it consistent with Python, not with an arbitrary set of
other languages.

> For truth testing of a value, one should use "if", e.g. "if x: print
> 'Yes'", not comparison to a truth value; "if x =3D=3D True: print 'Yes'=
"
> is not only wrong, it is also strangely redundant.

`if x:` is clear, concise, and generic. Adding comparions or
an explicit coercion to bool makes it ugly and more difficult
to read.

******

How will bool influence '__nonzero__'? Currently, Python insists that
'__nonzero__ should return an int'. Will this be changed to 'should
return a bool'?

As that would break existing code, I hope not.

-- =

Christian Tanzer                                         tanzer@swing.co.=
at
Glasauergasse 32                                       Tel: +43 1 876 62 =
36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 =
92