PEP 285: Adding a bool type: yes, but not as int subtype

[Bengt Richter]

On Mon, 01 Apr 2002 18:33:14 GMT, kzaragoza at attbi.com (Kris J. Zaragoza) wrote:

>In article <3CA79401.CFA41B65 at python.org>, Guido van Rossum wrote:
>> But see also my comments on these two in
>> http://www.python.org/doc/essays/pepparade.html; neither PEP is likely to
>> have any effect on Python's future.
>> 
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>Guido,
>
>I have to ask one question that I haven't seen brought up yet: What
>does PEP 285 imply for the future of Python?  Do you intend to
>eventually change the concept of what is true?
>
>Specifically, I refer to the Python Language Reference
>(http://www.python.org/doc/2.2/ref/lambda.html):
>
>"""In the context of Boolean operations, and also when expressions are
>used by control flow statements, the following values are interpreted
>as false: None, numeric zero of all types, empty sequences (strings,
>tuples and lists), and empty mappings (dictionaries). All other values
>are interpreted as true."""
>
>Do you intend to eventually (NOTE: I say eventually, I know it's not
>immediate) modify this to read that only the value True is true and
>the value False is false?  If this is the case, I believe this adds
>needless complexity to code whereas (in a simple case)
>
>if foo:
>    ...do whatever...
>
>would now have to read
>
>if bool(foo):
>    ...do whatever...
>
Perhaps this could be discussed in terms of hidden properties. I.e.,

    if foo:
    ... whatever

results is accessing foo's hidden boolean property because of the
'if'-context.

    bar = foo

binds bar to the foo object, not the value of the hidden property
this time, because of the '='-context. Some people get confused when
both types of access are used in the same expression, as in

    baz = foo or bar

Here, first foo's hidden boolean property is tested. It that is true,
then the value is foo as in '='-context. Similarly for bar.

Of course the 'hidden property' is only rhetoric here, but why not
make this a clear and controllable unified mechanism instead of a
collection of special effects? I would like to see an overridable
__bool__ method (not actually a programmatic property) for the base
object class, perhaps making deprecation of __nonzero__ possible.

Anyway, x.__bool__() would be the standard access mechanism for the
'hidden boolean property' of x, and plain x as usual in '='-contexts.

>in order to convert None, empty sequences/mappings, and non-integer
>zeros to boolean values.  It may seem like a small change, but it
>would add unnecessary verbiage to what is already fairly obvious in
>control constructs and other boolean expressions.
No verbiage would be necessary if the base classes had appropriate
__bool__ methods, and appropriate implicit conversions were done
for arithmetic contexts (e.g. indexing operators etc.)
>
>If you don't intend to modify this concept, then what's the real gain
>for the new boolean type?  The concept is already fairly clear, and
>would be needlessly muddied by this extra type that holds one of two
>values.  (Try explaining to a newbie that it's actually one of two
>pre-allocated instances!)
The benefit would be that you could derive from any object-based class
and customize your class's definition of instances' boolean values
in a standard way, as you saw fit. IOW, each class gets to modify the
concept for its own purposes.

bool(x) would call x.__bool__(), which would return a bool. If that were
done right, it should also be possible to return a subtype of bool that
had different str/repr so that print bool(x) might say, e.g.,
On/Off instead of True/False, and yet have subtype instance work
properly as a logic value.

>
>The only real advantage I can see in the latter case is to make some
>code a bit more self-documenting.  If you assign a value of False or
>True to a variable, it's pretty clear what that variable is intended
>to hold.  However, given the firestorm of discussion that has erupted
>around the details of this PEP, is this small gain really worth the
>effort?  Is there some other advantage I'm missing?
Well, what do you think of the above?

Regards,
Bengt Richter