[Python-Dev] For review: PEP 285: Adding a bool type
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".
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.
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?
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.
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