Comparisons and sorting of a numeric class....

[Andrew Robinson]

>> And most of this thread has been nothing more than me asking "why" 
>> did Guido
>> say to do that -- and people avoiding answering the question.
> Wait, are you actually asking why bool is a doubleton? If nobody has
> answered that, I think probably nobody understood you were asking it,
> because it shouldn't need to be explained.
In some ways, yes I am asking that -- but in another I am not;
to be more precise -- Why did Guido refuse to allow refinement of 
meaning when in industry -- logic equations generally are not limited to 
Charles Bool's original work, but include practical enhancements of his 
theories which make them far more useful.

A subclass is generally backward compatible in any event -- as it is 
built upon a class, so that one can almost always revert to the base 
class's meaning when desired -- but subclassing allows extended meanings 
to be carried.  eg: A subclass of bool is a bool -- but it can be MORE 
than a bool in many ways.

One example: It can also be a union. So when Guido chose to cut off 
subclassing -- his decision had a wider impact than just the one he 
mentioned; eg: extra *instances* of True and False.... as if he were 
trying to save memory or something.

The reason Guido's action puzzles me is twofold -- first it has been 
standard industry practice to subclass singleton  (or n-ton) objects to 
expand their meaning in new contexts, and this practice has been 
documented for many years.  So -- why did Guido go against the general 
OOP practice unless he didn't know about it?

The mere existence of a subclass does not threaten the integrity of 
bools or security in Python in any way I can see -- as one can do a type 
check, or a base type check, on an instance to decide how to handle a 
subclass vs. base class instance. So I'm guessing he was concerned about 
something else, but I don't know what.

In general -- it's not the goal of subclassing to create more instances 
of the base types -- but rather to refine meaning in a way that can be 
automatically reverted to the base class value (when appropriate) and to 
signal to users that the type can be passed to functions that require a 
bool because of backward compatibility.

> Boolean algebra has two values: true and false, or 1 and 0, or humpty
> and dumpty, or whatever you like to call them.
You're speaking to an Electrical engineer.  I know there are 10 kinds of 
people, those who know binary and those who don't.  But you're way off 
base if you think most industrial quality code for manipulating boolean 
logic uses (or even can be restricted to use) only two values and still 
accomplish their tasks correctly and within a finite amount of time.

>    The bool class
> represents the values of boolean algebra. Therefore, there are two of
> them. If I have an object that I know is an instance of bool, the
> implication is that it is one of those two values, not something
> potentially completely different.
>
> Can you name any other language that *does* allow subclassing of
> booleans or creation of new boolean values?
Yes. Several off the top of my head -- and I have mentioned these 
before.  They generally come with the extra subclasses pre-created and 
the user doesn't get to create the classes, but only use them; none the 
less -- they have more than two values with which to do logic equations 
with.

VHDL, Verilog, HDL, Silos III, and there are IEEE variants also.
C/C++ historically allowed you to do it with instances included, 
although I am not sure it still does.

The third value is usually called "TRI-state" or "don't care". (Though 
its sometimes a misnomer which means -- don't know, but do care.)

Most of these high definition languages are used to do things like 
design micorprocessors... eg: the very intel or arm processor you 
typically run python on --- because trying to do it with boolean logic 
and theorems of the past in a pencil and paper compatible strict 
re-incarnation of what Charles Bool's did in his own time (even if done 
by computer) -- rather than including De-morgan and all the many other 
people who contributed afterward -- is about as red-neck backward as one 
can get -- and often doomed to failure (though for small applications 
you might get away with it.)

Often, only one extra ( tri state ) value is needed to do logic 
verification and testing; but in some cases, notably, where the 
exclusive 'or' function is involved, the relationship between don't care 
inputs can become important and more values are required; eg: to detect 
when in deeply nested logic, various sources of don't care inputs 
interfere with each and themselves in constructive or destructive ways 
to produce constant logic Trues or Falses.

We've discovered that we live in a quantum-mechanical universe -- yet 
people still don't grasp the pragmatic issue that basic logic can be 
indeterminate at least some of the time ?!

The name 'boolean logic' has never been re-named in honor of the many 
people who developed the advancements in computers -- including things 
like data sheets for electronic parts, or the code base used for solving 
large numbers of simultaneous logic equations with uncertainty included 
-- which have universally refined the boolean logic meanings found in 
"Truth" tables having clearly more than two values -- but don't take my 
word for it -- look in any digital electronics data book, and there they 
will be more than two states; marked with rising edges, falling edges, 
X's for don't cares, and so forth.

Even though the BASE values are 1 and 0 in all the cases I've mentioned 
-- there is more to consider.

> That sounds like premature optimization to me. Always subclassing
> object when no more specific class is available would be a good habit
> to get into. The savings you're talking about are not that great, it
> will save you surprises when an old-style class doesn't do what you
> expect, and it will produce code that is more compatible with and more
> easily ported to Python 3.
Oh I agree -- but I meant e-mail space. Not just computer memory.
I wasn't going to use any of that in the example I showed D'Aprano and 
didn't want to bother to type it up.

The example was only meant to show three things:  I -- that a class type 
can be used to replace an instance variable for a method can be called 
on a class as opposed to only an instance  II -- that types and 
instances can both be arbitrarily placed in a list to determine their 
relative lexical sorting order. III -- that both of these things can be 
done without the class being instantiated.

All three of those things were demonstrated in the example -- so it was 
good enough for my purposes.  As to all of your other objections -- hell 
-- I never intended that example to be used in a real life situation 
beyond demonstrating the basic feasability of encoding data as a type.
As I said to D'Aprano -- even a *cursory* examination (eg: as in not 
detailed) shows I could do things which he wasn't considering.

>
>> This seems fine, but I don't get why you're messing around with
>> subclassing tuples. Do you really want to have boolean values that are
>> iterable, indexable, etc. for no reason? Just create a normal class
>> (or maybe subclass int, to match the normal bool class) and let your
>> instances contain a tuple instead of being one.
>>
>> Sorting traditionally allows and uses rich compares when sorting complex
>> data.  (cf. the email's name)  This point was examined  earlier in the
>> thread by another poster, who suggested I wrap my values in a list to 
>> allow
>> sort() functions to do a hierarchical compare.
>>
>> Although I couldn't implement the sort in the way that poster 
>> recommended
>> for various technical reasons -- none the less, their suggestion led 
>> to a
>> fruitful study of how and when sort algorithms do comparisons and 
>> what they
>> expect from them.
>>
>> The tuple, then, is a natural object to contain an actual instance of 
>> bool
>> (as opposed to a subclass) and work seamlessly with sorting algorithms
>> already available in python.
> Which doesn't answer my question at all: why inherit from tuple when
> composition would suffice? A boolean is not a tuple, so a boolean
> class should not subclass tuple. It sounds to me like you turn to
> subclassing as a solution much more quickly than is wise.
>
> As a final note, please only post plain text messages to this
> newsgroup, not html. Not everybody can easily read html messages, and
> as you can probably see from this post it can mess up things like
> reply quoting.

I don't have a setting on my email to turn off html.  Sorry. Can't help.

I don't know what you mean about composition vs. sub-classing.
Would you care to show an example of how it would solve the problem and 
still allow hierarchical sorting ?

I don't see how you can get pre-existing python functions (like sort, 
max, and min) to accept a complex bool value and have that value 
automatically revert to a True or False in an intelligent manner without 
overloading the operators defined in some class -- somewhere -- to 
operate on the data the class contains.

How do you intend to achieve that with this -- composition -- thing you 
mentioned ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150114/c9b9e026/attachment.html>