Comparison with False - something I don't understand

[John Nagle]

On 12/2/2010 10:13 AM, Terry Reedy wrote:
> Aside from the other issues raised, I will just note that is more common
> to return None when there is no answer (for whatever reason) rather than
> False and explicitly compare 'is None' than 'is False'.

    The basic problem is that the original design of Python lacked
a "bool" type.  Classic language design error.  It seems reasonable
to people not familiar with programming language history
to let True be equivalent to 1 and False be equivalent to 0, but
it doesn't work out well.

    Retrofitting a "bool" type never quite works right.  C/C++ went
through this decades ago.  The semantics of integers
are clear, and the semantics of booleans are clear, but the semantics
of mixed booleans and integers are not.  You get questions like the
one in this thread.

    Related questions include the semantics of

	x = True + True

What's the value of "x"?  "True"?  2?  Is "+" between
two "Bool" items addition, logical OR, or an error?
The same problem applies to "*".

    The arguments on either side can be seen in PEP 285, but
they gloss over the fact that the original design was botched.

    Similar design errors show up in other places in Python.
Using "+" for concatenation seemed reasonable, but didn't scale
out well, especially after NumPy's "array" type was introduced.

    [1,2,3] + [4,5,6]

and

    array([1,2,3]) + array([4,5,6])

produce quite different results.  Worse, what should

    array([1,2,3]) + [4,5,6]

do? It doesn't raise an exception.

I went to a talk by Alexander Stepanov at Stanford recently, where he
talked about problems in the fundamentals of programming.  This is
one of the issues that came up.  Defining addition in a way that
is not associative and commutative leads to problems, and breaks
generic algorithms.  If the basic operators follow the expected rules, 
generic algorithms will work on them.  That was botched in Python.

				John Nagle