PEP 285: Adding a bool type

[Steve Holden]

"Roy Smith" <roy at panix.com> wrote in message
news:roy-9E63B6.15273306042002 at news1.panix.com...
> Paul Sidorsky <paulsid at shaw.ca> wrote:
> > The proper course of action here would be to add a second check,
> > isPaid(), to wherever the new information is needed.
>
> Or, instead of isValid() and isPaid(), have a single method, getStatus(),
> which could return invalidAccount, paymentOverdue, or accountUpToDate.
Not
> all things fit into a boolean, but those that don't shouldn't be accessed
> by methods whose names begin with "is".  I guess the die-hard lispers
would
> say the same about names ending in "p" :-)
>
> The most fascinating (and often, frustrating) example I know of "almost
> boolean" is SQL's concept of NULL.  In what other language can "A == B"
and
> "A != B" both be false?  The problem is that they tried to cram two
> distinct concepts ("are the operands valid?" and "are the operands
equal?")
> into a single conceptual slot.

I don't think that's true. I think "they" required a value which
specifically indicated that data were unavailable, or irrelevant in certain
semantic contexts (such as the hourly rate of a salaried employee). The
result of the comparisons you quote is *neither* true *nor* false, it's
NULL.

Given the existence of such a value, the decision about what to return as a
result of operations on it (the same such value) appears reasonable and
well-founded to me.

The problem is not with SQL,but with our habit of thinking in two-valued
logic terms. Which is why, when I'm teaching SQL, I tell students that NULL
is an indispensable part of the language that they should avoid until they
understand why :-)

regards
 Steve