Comparisons and sorting of a numeric class....

[Gregory Ewing]

Andrew Robinson wrote:
> 
> I never said subclassing bool is the 'only' solution; I 
> have indicated it's a far better solution than many.

An assertion with which we very much disagree.

> I have spent well over 
> twenty years on and off dealing with boolean values that are very often 
> mixed indistinguishably with 'don't care' or 'tri-state' or 'metastable 
> states'.

I think you're overestimating how useful it will be to
pass one of your "extended boolean" values to existing
code expecting a plain boolean.

The purpose of the bool type in Python and other languages
is for making control-flow decisions. When you hit

    if x:
       do_something()
    else:
       do_something_else()

and x is Undefined or TriState or "47% true", what is
supposed to happen? The right thing to do will depend on
the circumstances, so you're going to need custom code
for dealing with those values.

I'm not even sure it's right to single out two of the
extended values as corresponding to True and False in
all cases. It may seem obvious that the "high" state
of a digital logic signal should be True and the "low"
state should be False, but -- what about active-low
signals? They use the opposite convention!

> Then I look at python development historically and look at the built in 
> class's return values for compares; and I notice; they have over time 
> become more and more tied to the 'type' bool.

Actually, it's the opposite. Originally, all the comparison
operators got funneled through a single special method __cmp__,
which was required to return a negative, zero or positive
integer; hard-coded logic in the interpreter then derived a
boolean from that.

When rich comparisons were introduced (i.e. the ability to
override all the comparison operators individually), that
restriction was lifted.

> I expect sometime in the 
> future that python may implement an actual type check on all comparison 
> operators so they can not be used to return anything but a bool.

That's not going to happen. If nothing else, it would
break NumPy, which compares arrays element-by-element and
returns an array of booleans.

> I already noticed a type check on the return value of len() so that I 
> can't return infinity, even when a method clearly is returning an 
> infinitely long iterator

That's acknowledged as being less than desirable, but
fixing it would have performance implications, as well as
breaking the C extension API.

It's not really much of a limitation, anyway. Iterators
don't actually have a __len__; they can optionally have a
__length_hint__ method, but infinite iterators can just
leave that undefined.

> That suggests to me that there is significant risk in python of having 
> type checking on all __xx__ methods in the future.

You need have no fear of that. The trend has actually
been towards *less* restrictions on return types, and
I can't imagine that changing.

>> - use delegation to proxy True and False;
> 
> That sounds like a far more likely to succeed alternative, and is one of 
> a handful of alternatives I have been exploring on my own.

A proxy is still a different type. Whether you use a
proxy or a completely new type for this is entirely a
matter of implementation convenience. You won't magically
gain any capabilities that you couldn't have implemented
otherwise.

> python may not be able to do it 
> totally from the python side because there is a difference in how Python 
> handles type() checks and isinstance() checks.

There's no way I know of to make type() lie about the
true type of an object, proxy or not. But that would only
be a problem for code relying on type(x) is bool, which
I expect to be extremely rare if it exists at all.

> Though I DO want to point out that Charles Bool did not invent the 
> computer,

That's correct, because he didn't exist. :-) Boolean algebra
is named after George Boole. You're probably thinking of
Charles Babbage, who design (although never fully implemented)
what could be regarded as the first general purpose programmable
computer.

> Name recognition is great for honoring a man -- but makes for a poor 
> reason to choose a strict implementation of bool.

This is utter nonsense. The "strict" implementation of
bool you speak of isn't chosen to honour George Boole.

It's chosen because it's perfectly suited for its intended
application of flow-control in programming -- which is the
vast majority of the use of logic *above* the hardware
level. And since it happens to be a true Boolean algebra,
the name is entirely appropriate.

>> And those truth tables are not part of Boolean algebra.
> 
> Oh wow!!!! I never expected to hear that --  But I guess you were never 
> trained to do boolean algebra, formally ?

A Boolean algebra is a mathematical structure with a precise
definition. There exist Boolean algebras with more than two
values, but the don't-care states found in data sheets don't
fit into any of them. The data sheets call them "truth tables",
not "Boolean algebra tables". :-)

> The truth tables on data sheets are VERY VERY much intended to be 
> related to boolean logic.

Related, yes. Boolean algebra is a part of those truth tables,
not the other way around. What Steven said is correct.

-- 
Greg