Meaning of None - was PEP 285: Adding a bool type

[Colin J. Williams]

Huaiyu Zhu wrote:

>
> I had also proposed this as a way to properly define rich comparisons:
>
>         a   b   a > b   a == b   a < b
>         1   0   True    False    False
>         0   0   False   True     False
>         0   1   False   False    True
>         0   1j  None    False    None

This raises a different issue than was raised initially.
For the last case a > b and a < b are treated as
incompatible types and raise exceptions.

>
>
> It is often necessary to compare objects in a set even though there is only
> a partial order.  We often do not want exceptions when the order is not
> defined, since comparisons are often imbedded in expressions but try/except
> has to be statements.

Correct, but I was addressing the case where one might get
a NULL value from a database.  In this case, the NULL
typically indicates that a value is unknown, not available
or even inappropriate.

Suppose A= 25 and B=NULL and we:
assert A>B

Currently, no exception is raised.  This is correct when
we have certainty as to whether A>B, A==B or A<B.

However, when the value of B is currently unknown and
perhaps even unknowable, would it not be better to return
a value other than True or False which indicates this
uncertainty?

Colin W.

>
>
> On the other hand, a comparison operator with a total order is useful in
> many situations even though this total order is not related to the _natural_
> partial order.   For example, cmp(1, None) is well defined.  Why would
> cmp(1, 1j) be an exception?   This is especially painful if all you want is
> just a _unique_ order, whatever it is.
>
> Anyone paying attention to such matters over time would discover that
> allowing three valued logic would solve a supprisingly large number of
> trivial but nasty problems.
>
> However, I do not see an easy way to extract None from Python's pool of
> objects denoting false.  If only it was not designed that way ...
>
> Hopefully when IEEE floating point support becomes ubiquitous we could
> redefine the comparison with NaN for this purpose.  (You might be able to
> get at it now as NaN=(1e200j**2).imag, but the comparison is always False.)
>
> Huaiyu