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

[Guido van Rossum]

> Current Rationale for PEP 285:
> 
>     Most languages eventually grow a Boolean type; even C99 has one.
>     It's useful to be able to tell from a function result that the
>     outcome has Boolean semantics, and it helps with things like RPC
>     protocols that may prefer to encode Booleans differently from
>     integers.
> 
> I'd like to get a clearer understanding of the rationale of adding a new
> type which would become commonly used, in view of the cost of the change
> (in terms of complexity, backwards compatibility issues,
> development/debugging time, outdated docs, etc.).

Yeah, there's always a lot of things that must be changed...

Most Python documentation currently contains some sort of apology for
the fact that there's no separate Boolean type, so at least the change
in the docs would be a positive one.

> I think it's key to identify the ways in which the current semantics and
> idioms are suboptimal.
> 
> 1) "Most languages eventually grow a Boolean type; even C99 has one."
> 
> While I've often wanted a boolean (mostly for 'aesthetic reasons'), I
> think it's important that the rationale for a language modification be
> deeper than "everyone else does it".

It is commonly seen as a small wart.  While the wart is easy to work
around (I've seen lots of code defining constants True and False or
variations), what's missing is a standard way so everybody can do it
the same way.

> 2) "it helps with things like RPC protocols that may prefer to encode
> Booleans differently from integers."
> 
> That is a real issue except that it seems to have been solved relatively
> well by all of the language bindings so far.  IIRC, there are some
> awkward situations in Jython if you explicitly want to send a boolean to
> a polymorphic function, but that's an edge case.

I didn't invent this argument; Marc-Andre thought it would be
helpful.  I see it as a mild argument at most.  But it's useful that
in situations where a receiver would like to distinguish Booleans from
ints, you can now do it.

> 3) "It's useful to be able to tell from a function result that the
>     outcome has Boolean semantics"
> 
> This is intriguing.  I can't think of a case where the current integer
> return values have caused me problems or concerns that weren't solved by
> simply understanding what the function was about.  What use case did you
> have in mind?

When showing people comparison operators etc. in the interactive
shell, I think this is a tad ugly:

    >>> a = 13
    >>> b = 12
    >>> a > b
    1
    >>>

If this was:

    >>> a > b
    True
    >>>

it would require one millisecond less thinking.

There's also the issue (which I've seen puzzling even experienced
Pythonistas who had been away from the language for a while) that if
you see:

    >>> cmp(a, b)
    1
    >>> cmp(a, a)
    0
    >>> 

you might be tempted to believe that cmp() also returned a truth
value.  If ints are not (normally) used for Booleans results, this
would stand out much more clearly as something completely different.

> 4) Booleans lead quickly to the 'memory savings' notions of packed
> arrays of bits, which seems a detail of array implementation issues
> different from this proposal.  I think the array folks could implement
> this w/o a "core" Python datatype, just like they/we've dealt with
> low-precision floats.

This doesn't interest me much.

> All in all, I'm neither for nor against at this point, but I think the
> rationale for the change needs further elaboration.  And feeling
> conservative today, without that I'd vote against it on complexity
> grounds.

Wait till you've seen the implementation. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)