PEP 285: Adding a bool type

Brett Cannon bac at OCF.Berkeley.EDU
Sat Mar 30 04:39:52 EST 2002


On Sat, 30 Mar 2002, Guido van Rossum wrote:

[snip]
>     1) Should this PEP be accepted at all.
>

Personally, I feel no great need for booleans, but it wouldn't hurt to
have them either.  We all do the usual return 1 if true else return 0
standard on boolean-like methods, so it isn't like they would go unused.

But we do have that basic standard going and it is not that much more code
to handle.  Python has always gone for verbose over shortcuts, and I can
easily view booleans as just a shortcut to appease people from other
languages.

Personally, I would give a +0 vote just because this is a common enough
case that a shortcut would be nice.


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

Return "True".  I agree on the strange looking part.  Plus we can only
bend over backwards so much for compability.  I doubt the amount of code
that would be broken justifies the strangeness of returning "1".


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

If this is done, make it Pythonic.  If we cared about being like other
langauges we wouldn't use Python because of that "funky whitespace
mattters stuff" issue.  Go with '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.

I agree with this.  Thanks to the standard way of representing false as 0
and true as everything else (but almost always as 1), I see no reason to
not treat it as such behind the scenes in terms of operations.  Allows all
of us warped by C to continue to fool ourselves into treating boolean
values as ints.


>
>     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 say return boolean.  This goes back to my view of not worrying about
backwards compatibility as much as general correctness and being more
Pythonic.

This whole thing is in a way saying that we should have had booleans a
while back.  So why not just do a complete cleanup of the situation and do
it right.


>     Many programmers apparently feel the need for a Boolean type; most
>     Python documentation contains a bit of an apology for the absence
>     of a Boolean type.  I've seen lots of modules that defined
>     constants "False=0" and "True=1" (or similar) at the top and used
>     those.  The problem with this is that everybody does it
>     differently.  For example, should you use "FALSE", "false",
>     "False", "F" or even "f"?  And should false be the value zero or
>     None, or perhaps a truth value of a different type that will print
>     as "true" or "false"?  Adding a standard bool type to the language
>     resolves those issues.
>

Consistency is obviously the big draw for this.  Since truth can be viewed
as anything not 0 or None, it is rather open and not standardized
officially.  But we all treat 1 as true and 0 or None as false already.
Plus if someone feels the need to have the syntactic sugar for True and
False, they can do it themselves as mentioned above.

But the frequency of this in code, IMO, is frequent enough to warrant at
least considering the sugar.  Everyone uses booleans in there code in some
form.  And if having a standardized way of representing them makes
maintaining code that much easier, so be it.

-Brett C.




More information about the Python-list mailing list