[Python-Dev] For review: PEP 285: Adding a bool type (original) (raw)

David Ascher DavidA@ActiveState.com
Fri, 08 Mar 2002 11:04:15 -0800

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

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

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

  1. "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?

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

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.

--david