PEP 285: Adding a bool type

[Ken Peek]

Guido van Rossum <guido at python.org> wrote in message news:<mailman.1017495346.22278.python-list at python.org>...
> > [Guido]
> > >>     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.
> > 
> > [Ralph Corderoy]
> > > Unlike Tim to produce such a poor reason.  Has he been paraphrased a
> > > little too much?
> 
> [Tim]
> > Not in Guido's eyes <wink>.  We don't need 3 equivalent ways to turn an
> > arbitrary expression into a bool ("bool(x)" same-as "not not (x)" same-as
> > "truth(x)").  *Especially* if str(bool) and repr(bool) produce 'True' and
> > 'False', people have a legitimate need to make an arbitrary true/false
> > expression produce 0 and 1 too, if only to preserve 0/1-based true/false
> > output.  operator.truth() has always been the best way to do exactly that.
> > Alternatives like "(boolexpr) + 0" and "(boolexpr) and 1 or 0" and "(0,
> > 1)[boolexpr]" reek in comparison.
> 
> Tim must be missing something.  The obvious way to turn a bool b into
> an int is int(b).  Having to import the obscure 'operator' module for
> this purpose is backwards.  (IMO there's almost *never* a reason to
> import that module anyway.)
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

I don't see that adding a "bool" (or better: "boolean", since I HATE
abbreviated words) would be such a big issue.  This would allow for
better "readability" of the code.  ("Readability" being defined as
maximally exposing the intentions of the programmer to the largest
audience of readers as is practical.) Comparison operators (under the
hood) should return a "boolean", so that if you type:

>>> 1 < 2
True
>>> 1 > 2
False

Yes-- I think there should have to be some type conversion required if
you need to use your boolean in an expression.  The idea being, that
you shouldn't be using a "boolean" in an expression anyway, unless it
is some kind of obscure programming trick (which should be depricated
anyway.)

If no one can agree on how the boolean type should be implemented,
then leave it the way it is, and add a "readonly" keyword-- which
would be useful for other constants as well:

readonly:
    # attempts to write to these will throw a
    # "TypeError: attempted write to a constant"
    False = 0
    True = 1
    MY_CONSTANT = 42

As to the case of the keywords-- well, I prefer all uppercase for
constants, because I think they stand out better when reading code.  I
don't think this should be forced by the language though-- let people
do whatever they want-- why be a baby sitter?

Regardless of whether or not a boolean type is implemented-- in my
code, I would simply define:
TRUE = True
FALSE = False

And if the 'readonly' construct is implemented:
readonly:
    TRUE = True
    FALSE = False

I then use TRUE and FALSE in my code instead of True and False. 
Problem solved (for ME anyway).  The 'readonly' keyword would be VERY
helpful though (to catch programming mistakes)-- which happen a lot
for me, anyway...