PEP 285: Adding a bool type

[Bengt Richter]

On 7 Apr 2002 15:14:37 GMT, ralph at inputplus.demon.co.uk (Ralph Corderoy) wrote:

>Hi Max,
>
>> > I think we all perfectly understand your opinion too and no matter how
>> > many times you repeat it there will still be some of us that like to do
>> > 
>> >     a = b + is_movable(c
>> 
>> I can see that it is clever, but I don't get why it is smart. Isn't it 
>> just another way of writing?:
>> 
>>      if is_movable(c):
>>          a = b + 1
>
>No.  BTW, you snipped a closing parenthesis there.
>
>It's equivalent to
>
>    a = b
>    if is_movable(c):
>        a += 1
>
>or
>
>    if is_movable(c):
>        a = b + 1
>    else:
>        a = b
>
>or
>
>    a = b + is_movable(c) ? 1 : 0
>
>but that last one isn't valid Python but does show a strong C
>background is likely to make you familiar with this approach.
You could write that in Python as

    a = b + (is_movable(c) and 1 or 0)
>
>> If it is, I find that it is more obfuscation than expression. It's
>> akind to using a magic value. My paraphrase of our code should really
>> read something like::
>> 
>>      motionLength = 1
>>      if is_movable(c):
>>          a = b + motionLength
>
>That doesn't cover `not is_movable(c)' again.
>
>> Or your code should possibly have read::
>> 
>>      a = b + motionLength(c)
>> 
>> But probably I misunderstand you intentions.
>
>The quantity being added to b isn't a length, it's 1 indicating that c
>is movable.  Trying to name it anything other than what it is is
>contortion for some ideal that doesn't work in this case.
You could write

      a = b + oneIfMovableZeroIfNot(c)

if you wanted to be conspicuously clear about your function's intent.

>
>Say you had a list of items and wanted to sort them to place those with
>the most abilities first, with all abilities considered equal, and then
>sorting on the item's name where two have the same number of abilities.
>
>To calculate the major sort key you might do
>
>    major = can_be_moved(o) + can_be_sized(o) + can_be_stacked(o) +
>        can_be_coloured(o) + can_be_hidden(o)
>
It would express the semantics better if these were true boolean functions
returning True or False, and you wrote it as

    major = [can_be_moved(o), can_be_sized(o), can_be_stacked(o),
             can_be_coloured(o), can_be_hidden(o) ].count(True)

There is not much ambiguity in this form, whereas doing arithmetic leaves
a lingering doubt as to whether someone has 'enhanced' one of the can_be_'s
to give extra weight to one capability without renaming the function appropriately.

Using the new bools as return values does resolve the ambiguity and makes the
arithmetic usage an acceptable convention, though it requires that mental cast
from the true/false semantics of typical function names to 1/0 return values.
In some cases I suppose the better (I assume) speed of the arithmetic may be important.

>as opposed to
>
>    major = 0
>    if can_be_moved(o):
>        major += 1
>    if can_be_sized(o):
>        major += 1
>    if can_be_stacked(o):
>        major += 1
>    if can_be_coloured(o):
>        major += 1
>    if can_be_hidden(o):
>        major += 1
>
>I think the former is way clearer, and not because it uses less
>key-strokes, although brevity can aid clarity sometimes.
I think it is less cluttered, but it is more ambiguous (unless plainly
using the new bools), and that is not really clearer.

When you have your own usage conventions and have written the code
yourself, it is easy to take meanings for granted, and have no doubts,
but others may not have such faith in your adherence to a convention
unless you document it one way or another. One way is unambiguous code.
Another is a docstring comment like

"""Note: all is_xxx and can_be_xxx functions defined in this module
are guaranteed to return 1 if xxx is true and 0 if xxx is false."""

Personally, I prefer to read unambigous code, and not have to refer
to supporting documentation that I may have to double check anyway
by reading function source, if I'm doing a serious review, e.g., chasing
a bug. The new bools will help, since the arithmetic values can only be 0 or 1,
and that is unambigous where integer function return values are not.

Regards,
Bengt Richter