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 ?
--
https://mail.python.org/mailman/listinfo/python-list
