Fwd: Re: Comparisons and sorting of a numeric class....

[Andrew Robinson]

-------- Original Message --------
Subject: 	Re: Comparisons and sorting of a numeric class....
Date: 	Mon, 26 Jan 2015 05:38:22 -0800
From: 	Andrew Robinson <andrew3 at r3dsolutions.com>
To: 	Steven D'Aprano <steve+comp.lang.python at pearwood.info>



On 01/24/2015 12:27 AM, Steven D'Aprano wrote:
> Andrew Robinson wrote:
>
>> But let me explain a bit more why I'm picking on Python:  For even if we
>> set the electronic engineering concerns aside that I've raised (and they
>> are valid, as OOP is supposed to model reality, not reality be bent to
>> match OOP) -- People's facile explanations about why Python's version of
>> bool is the way it is -- still bothers me here in the python mail list
>> -- because people seem to have a very wrong idea about bool's nature as
>> a dualton being somehow justified solely by the fact that there are only
>> two values in Boolean logic;
> Nobody has suggested that except you.
Yes, they did 'suggest' it.
> Earlier I even stated that I didn't
> know GvR's motivation in making True and False singletons, but suggested
> that it might have been a matter of efficiency.
True... but you are not the only person on this list.

Although I seriously doubt that either efficiency, or memory
conservation plays a part in this in any meausrable manner.  eg: You
accused me of 'pre-optimizing' earlier, and if anything looks like a
pre-optimization, it's the bool itself because computers have tons of
memory now, and I seriously doubt modern Python versions can even run in
a small micro-controler; eg: without an almost complete rewrite of the
language....and as far as efficiency, I know speed won't change
significantly whether or not a singleton, or multiple instances are
allowed except under very unusual circumstances.  So, even now -- I have
no idea why Guido chose to make bool so restrictive other than because
he thought C++ was absolutely restrictive, when in fact C++'s type
system is more flexible than he seems to have noticed.

>> -- And I know
>> Charles bool didn't use singletons in his algebra,  -- just read his
>> work and you'll see he never mentions them or describes them, but he
>> does actually use dozens of instances of the True and False objects he
>> was talking about -- for the obvious reason that he would have needed
>> special mirrors, dichroic or partially silvered, to be even able to
>> attempt to make one instance of True written on paper show up in
>> multiple places; And that's silly to do when there's no compelling
>> reason to do it.
> In the words of physicist Wolfgang Pauli, that is not even wrong.
>
> http://en.wikipedia.org/wiki/Not_even_wrong
>
> I'm actually gobsmacked that you could seriously argue that because Boole
> wrote down true and false (using whatever notation he choose) more than
> once, that proves that they aren't singletons. That's as sensible as
> claiming that if I write your name down twice, you must be two people.
Clearly: Charles bool did not use singletons, and you are wasting your
breath splitting hairs that are moot.
>> Yet -- people here seem to want to insist that the bool type with only
>> two instances is some kind of pure re-creation of what Charles Bool
>> did -- when clearly it isn't.
> Nobody has argued that Boole (note the spelling of his name) considered True
> and False to be singletons. Being a mathematician, he probably considered
> that there is a single unique True value and a single unique False value,
> in the same way that there is a single unique value pi (3.1415...) and a
> single unique value 0.
The spelling caveat is great -- and in Python the object named in bool's
honor is spelled bool (lowercase too). ;)  another point about the
inconsistency of the object with the historical author, I just love it,
which is part of why I'm going to keep on spelling it like that!!!!  For
even the spelling, suggests Python is really acting like a lemming and
just doing bool because Guido though other lanugages do bool...   so
I'll just continue because it's fitting that anyone who mocks my use of
the mis-spelling bool also mock's Python's.

>
> But "the number of instances" and "singleton" are concepts from object
> oriented programming, which didn't exist when Boole was alive.
Yep -- I made that point myself in an earlier e-mail.  Do you feel
brilliant, or something, copying my remarks ?

>   It is not
> even wrong to ask the question whether Boole thought of true and false to
> be singleton objects. He no more had an opinion on that than Julius Caesar
> had an opinion on whether the Falkland Islands belong to the UK or
> Argentina.
Oooooh!  So you want people to think you commune with the dead, and know
he never thought about it alive and/or dead?  D'Aprano speaks
posthumously for Dr. bool ?

You're being very condescending and arrogant and arguing in pointless
circles!

I said, and I quote "He didn't use singletons in his algebra" -- if you
can show where he did, I'll retract my remark; otherwise -- you're
merely proving my point.

>> It's a amalgamation of enhancements such
>> as binary words instead of just True/False and many other things
>> (operators that work on words rather than single bits.).  So -- I don't
>> see that Python's implementation of Bool is justified by either a purist
>> appeal to Charles bool, or by ignoring pragmatic concerns that have been
>> attached to Bool's work for years by Electrical Engineers in order to
>> make it more useful for practical computer problems.  Yet these two
>> things are what this python list has sort of harped on.
> Python's bools are objects, and they represent Boolean values, not strings,
It's far more likely in my experience that an object in a computer *at
least* represents what can actually be found in the code of that object,
rather than trying to claim objects in python have nothing to do with
what is found in the object.  I *DO* know that the bool *object* in
python certainly does represent a string, in the repr() method; eg:
"True" or "False" strings to be precise.

So:  Where exactly is this boolean 'value' in the computer that you are
harping on, and what does it consist of ?  The moment you point out
where it is -- I will point out, that it is likely transmitted by wires
which were designed by engineers using HDL's, or else, you're going to
point to something containing a string, or an integer, but whatever it
is -- I know for sure it's not some mythical 'bool' in reality.

The bool values you seem to want to talk about exist only in your mind,
and you can't actually show them to me;  they aren't real objects in
Python or a computer.  Your whole argument is non-falsifiable and rather
pointless as far as I can tell.

> not lists, not floats, and not three-value or four-value logic values. They
> are designed for Boolean two-valued logic, like the bulk of programming
> languages, not for simulating hardware.
That's a non-sequitur, and downright lame.

I showed Ian a way to do what I wanted to do in C++, so the bulk of
programming languages is irrelevant as each has their own quirks and
work arounds; and you obviously don't know that most engineers use
programmable logic in their projects, now, so they use HDL's in
*synthesis* mode not just 'simulation'. The vast majority of all
hardware projects done today are built using this supposed 'niche' you
talk about;  I can, for example, build a complete web site using a
XILINX FPGA and a HDL language without ever using C/C++ or Python or
intel processor or any other dumbed down 'bool' based language you can
think of.  The difference is that HDL's are meant to ultimately
instantiate objects into hardware rather than create a software solution.

...snip...

>
> [...]
>> Where python is different from other languages regarding bool -- and
>> deserves a little extra picking on, is that Guido has imposed four
>> constraints simultaneously to bool which together cause a conflict
>> that I don't think (offhand) I've ever encountered in another language;
>> Definitely not in C/C++!
>>
>> The four things are: 1 -- he cut off subtyping and created no alternate
>> method of doing type checking of duck-types,
> The point of duck-typing is that you *don't* type check,

Gee... you are acting rather inconsistent for someone with so much
programming experience.
You do a duck type check by testing if it acts like a duck.... obviously!

But, I was also referring to how the built in Python type() function is
strict -- eg: a duck type "FAILS" a standard type check (in general).
There is no alternate way to get duck types to pass *existing* type()
checks -- and yes, Python DOES type() check in various places whether or
not I or you want it to! ; and other programmers can call type() in
their legacy code, too.

Hence, duck types often *don't work* because there is no way to
circumvent type() checks that already exist in the Python language, and
for this very reason a simple google search will reveal bug reports
where people are asking Guido to remove type checks altogether in
various places in python 3 precisely because duck types fail to work in
those places.  ( I wouldn't mind if they were gone. )

I really don't have time for the rest of your email; it's pointless...
A lemming is, as a lemming does...




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