Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #83651 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-12 17:59 -0800
    Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve@pearwood.info> - 2015-01-13 05:32 +0000
      Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-13 17:13 +1100
      Re: Comparisons and sorting of a numeric class.... Terry Reedy <tjreedy@udel.edu> - 2015-01-13 05:49 -0500
        Re: Comparisons and sorting of a numeric class.... Marko Rauhamaa <marko@pacujo.net> - 2015-01-13 13:00 +0200
          Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-13 22:20 +1100
          Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-13 11:56 -0700
          Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-14 06:02 +1100
      Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-13 21:56 +1100
      Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-13 16:12 -0800
      Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-14 01:31 -0700
      Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-14 22:26 -0700
        Re: Comparisons and sorting of a numeric class.... Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-16 22:23 +1300
      Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-14 23:23 -0800
        Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve@pearwood.info> - 2015-01-15 08:41 +0000
          Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-15 17:45 -0800
            Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 18:33 +1100
            Re: Comparisons and sorting of a numeric class.... Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 00:07 +1300
            Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-16 03:22 -0800
            Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 23:27 +1100
          Re: Comparisons and sorting of a numeric class.... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-16 02:27 +0000
          Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-15 22:01 -0700
          Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-16 17:58 +1100
        Re: Comparisons and sorting of a numeric class.... Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-01-15 09:54 -0800
          Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-26 15:47 -0800
          Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-26 18:50 -0700
      Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-15 10:05 -0700
      Re: Comparisons and sorting of a numeric class.... Andrew Robinson <andrew3@r3dsolutions.com> - 2015-01-23 03:46 -0800
        Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 07:31 -0800
          Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-23 09:50 -0700
            Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 09:03 -0800
              Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-24 04:23 +1100
                Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 09:29 -0800
              Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-23 11:04 -0700
                Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 19:13 -0800
                Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 19:21 -0800
              Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 16:01 +1100
                Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-24 16:43 +1100
            Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 09:22 -0800
              Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-24 04:37 +1100
                Re: Comparisons and sorting of a numeric class.... Rustom Mody <rustompmody@gmail.com> - 2015-01-23 09:45 -0800
                  Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-24 05:03 +1100
                  Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-23 11:13 -0700
        Re: Comparisons and sorting of a numeric class.... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 19:27 +1100
      Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-23 22:58 +1100
      Re: Comparisons and sorting of a numeric class.... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-23 12:07 +0000
      Re: Comparisons and sorting of a numeric class.... Terry Reedy <tjreedy@udel.edu> - 2015-01-23 11:17 -0500
      Re: Comparisons and sorting of a numeric class.... Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-23 11:00 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#84366

On Friday, January 23, 2015 at 11:07:48 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Jan 24, 2015 at 4:22 AM, Rustom Mody  wrote:
> > Strikes me that making enumerations is-equal rather than just
> > =-equal is a bit heavy-handed and unnecessary
> > What do you think?
> 
> *Normal* use of an enumeration does make sense for them to be
> identical. Classic use would be like this:
> 
> class AnsiColor(IntEnum):
>     black = 0
>     red = 1
>     green = 2
>     orange = 3
>     # ... blue, magenta, cyan, white
>     bold_black = 8
>     bold_red = 9
>     # etc etc etc
>     bold_orange = 11
>     yellow = 11 # On many screens, bold orange looks more yellow
> 
> There is absolutely no difference between the ANSI color "bold orange"
> and the ANSI color "yellow". So you would expect them to be identical:
> 
> >>> AnsiColor.yellow
> <AnsiColor.bold_orange: 11>
> >>> AnsiColor.yellow is AnsiColor.bold_orange
> True
> 
> And they are. There's simply no use-case for equal-but-distinct
> tokens, when you're primarily using this to give names to numbers. For
> another example, you could localize all the color names, or use
> "bright" instead of "bold", or drop the underscores; but ultimately,
> if you send "\e[11m" to the console, you're going to get the same
> color, whether that 11 was called "bold_orange" or "jaune".
> 
> What you're trying to do here is a hack, so it's no surprise that the
> system doesn't properly support it.
> 
> ChrisA

No disagreement with the 'hack'
As for "no use case for equal but distinct tokens" - thats a strange
view given this thread

[toc] | [prev] | [next] | [standalone]

#84375

On Sat, Jan 24, 2015 at 4:45 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> No disagreement with the 'hack'
> As for "no use case for equal but distinct tokens" - thats a strange
> view given this thread

Look at it this way: A classic enumeration has no use-case for
equal-but-distinct; this thread doesn't disagree with that, because
this thread is not about classic enumerations. In the same way,
integers don't have use-cases for equal-but-distinct either, but in
practice, you can distinguish between exact literals and the results
of computation:

rosuav@sikorsky:~$ cat unique_numbers.py
x = 100000
y = 100000
z = 99999+1
print(x is y, x is z, y is z)
rosuav@sikorsky:~$ python3 unique_numbers.py
True False False

This is still not good code, though. If you really need to distinguish
those, your code is majorly fragile.

ChrisA

[toc] | [prev] | [next] | [standalone]

#84380

On Fri, Jan 23, 2015 at 10:45 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> No disagreement with the 'hack'
> As for "no use case for equal but distinct tokens" - thats a strange
> view given this thread

If you want equal but distinct, you can give them distinct values and
define an __eq__ method that compares them as equal. Because of this
though I do take some issue with the Planet example in the docs:

https://docs.python.org/3/library/enum.html#planet

If any planets happened to have the same mass and radius (which I
realize would be unlikely in this case), the example would fail. Using
the value of the enum for both identity and data conflates the two
concepts and leads to pitfalls.

[toc] | [prev] | [next] | [standalone]

#84448

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. 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.

Right here, right now, the reason doesn't matter. It doesn't matter if some
other language chooses differently, or that Python might have been designed
differently. What matters is:

(1) Python is the way it is, not the way it might have been had it been
designed differently;
(2) it isn't going to change; and
(3) it doesn't matter for what you are trying to do.

You have invented an imaginary problem then spent your time complaining that
Python doesn't allow you to solve this non-existent problem in a specific
way.


[...]
> -- 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.


> 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.

But "the number of instances" and "singleton" are concepts from object
oriented programming, which didn't exist when Boole was alive. 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.


> 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,
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. You might as well be complaining
that Python's bools are no use for doing vector arithmetic. Correct. That's
not what they're designed for. If you want vectors, don't use a bool, write
a vector class.

Three- or four-value logic is of great use to the hardware engineer making
electrical circuits, we get that, thank you. But they are of little use in
solving most programming problems, which is why no general purpose
programming language I am aware of supports non-Boolean logic in the
language itself.

Simulating physical hardware is a niche. I am impressed by your anecdote of
running Python on an operating system running on a simulated computer,
that's very impressive, but it is still a niche requirement.


[...]
> 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, not that there is a
special kind of thing called a "duck-type" that you need to check for. Nor
is there some sort of special test for "duck-typing" (although abstract
base classes and isinstance comes close). If you write something like this:

    if isinstance(flag, bool):
        if flag: do_this()
        else: do_that()

that is the opposite of duck-typing. This is duck-typing, where you just
assume that your object is of the expected type and allow it to raise an
exception if it isn't:

    if flag: do_this()
    else: do_that()

Ironically, duck-typing bools is almost unique in Python in that it is
virtually impossible for this to fail. By default, every object regardless
of its type (list, int, str, one of your 4-value logic instances,
everything) can successfully be used as if it were a bool. This makes your
insistence that you have to subclass bool even more inexplicable.


> 2 -- he does not allow 
> multiple instances,  3 -- he himself did not implement bool using the
> standard alternative methodology to subclassing -- eg: as a composite
> structure with delegation. 

3 is irrelevant. Just because the bool type is "final" (in Java terms) and
un-subclassable doesn't mean that its parent must also be "final".

Subtyping int is allowed. There is no restriction on subtyping int to make
bool, and indeed you can subtype int to make your four-value logic class if
you wish.


> 4.  and he has made bool into the default 
> return type for base type comparison operators; which means that general
> programmers expect a bool for base types and may check for it, even if
> Python's built in functions do not.

Believe me, nobody writes code like this:

flag = x < y
if not isinstance(flag, bool):
    raise TypeError('expected bool, got something else')
if flag:
    print "x is less than y"


when they can write:

if x < y:
    print "x is less than y"


Provided your 4-value logic instances support conversion to bool via the
__bool__ special method (Python 3) or __nonzero__ special method (Python
2), it will be exceedingly rare that anyone will notice that your
fuzzy-numbers return MaybeFalse instead of False (etc).

The only time somebody will notice is if they pass the comparison result to
a flag which insists on a bool and nothing but a bool:

def somefunc(flag):
    if not instance(flag, bool): raise TypeError
    ...


somefunc(fuzzy_a < fuzzy_b)


But you can't solve every example of bad programming! What if the function
was written like this?

def somefunc(flag):
    if not (flag is True or flag is False): raise TypeError
    ...


That will reject your MaybeFalse and MaybeTrue *no matter what you do*. (You
cannot override identity checks in Python.) The only solution is to educate
your users that, *if and only if* they need to pass a fuzzy-bool to
something which requires an actual bool, they can explicitly normalise it
using:

somefunc(bool(fuzzy_a < fuzzy_b))


[...]
> As far a subtyping goes; The very fact that Guido used subtyping to
> create bool in the first place (subtype of int), precludes any real
> claim that bool should not itself be subclassable 

That's simply wrong.

Have you heard of the saying "Don't run with scissors",  usually told to
small children? (I know a nominally mature adult who stabbed himself after
tripping over while running with scissors. Oh how we laughed. Fortunately
his injury was mild and more embarrassing than life-threatening.)

Scissors are usually made from pieces of steel. Would you argue this?

"There is no prohibition on running with arbitrary pieces of steel. Scissors
are made from steel. Therefore, that precludes any claim that we should not
run with scissors."

That int is subclassable has no bearing on whether or not bool (made from
int via subclassing) is subclassable.



> just because bools 
> only have two values;  I mean, seriously --  Guido's 'strict' Bool is
> already an impure form of OOP that is borderline hypocrisy, as it can
> '+' to 2 or 3... 

Not in the least.

Python's bools are "impure" only in the sense that they violate some
people's expectations that bools should be an abstraction. In the case of
Python, they are not abstractions, they are ints. (Specifically a subclass
of int.) But by the rules of OOP, including the Liskov Substitution
Principle, bools are perfectly good ints. Anywhere you use an int, you
could use a bool instead, and they will work.

Personally, as an ex-Pascal programmer, it took me a long time to get used
to the fact that True and False weren't purely abstract values with no
methods and no operations other than `or`, `and`, `if...else`. But I not
only got used to it, but I came to appreciate that this is actually useful.


> and many other things;  and worse I've just come across 
> a couple of papers which suggest that Guido doesn't like subclassing
> when Composite object structures could be used instead to replace the
> subclass 'is' relationship with a 'has a' relationship.

I would like to see these papers.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#84340

On Fri, Jan 23, 2015 at 10:46 PM, Andrew Robinson
<andrew3@r3dsolutions.com> wrote:
> 4.  and he has made bool into the default return type for base type
> comparison operators; which means that general programmers expect a bool for
> base types and may check for it, even if Python's built in functions do not.

I don't get this. They're specifically documented as NOT being
required to return a bool, so if any code is type-checking the return
values, that code is buggy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#84342

On 23/01/2015 11:46, Andrew Robinson wrote:
>

Unless I've missed something all you've done is show that you haven't 
got the faintest idea what you're talking about.  Would you either 
please go away before I die laughing, or tell me where you get the stuff 
that you're taking.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#84351

On 1/23/2015 6:46 AM, Andrew Robinson wrote:

> -- 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; For, singletons style programming is not
> justified by the number of values an object has in reality -- 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

In mathematics, as conceived by most mathematicians, there is only one 
instance of each immutable value.  Value is identity. There is only one 
immutable empty set. (This, without the assumed 'immutable' added, is a 
quote from beginning set theory texts written to counteract the beginner 
mistake, here repeated by you, of thinking that there might be more than 
one.)  There is only one 0, one 1, one (immutable) set {0, 1}, and one 
one symbol 'a'.  The notion of identity separate from value is only 
needed for mutable objects, which generally do not appear in math.  So 
unless Boole was an oddball among mathematicians, he considered multiple 
instances of the word 'True' to be multiple references to the one and 
only logical value True.

In Python, any immutable instance *could be* a singleton.  In current 
CPython, the ints -10 to 256 *are* singletons.  In 'x = 1 + 1', the two 
1s are the same 1.  Other ints are not made to be singletons only 
because the cost would be greater than the benefit.  Similarly, ascii 
chars are singletons and some other strings are interned to make them 
singletons.  Also, the empty tuple is a singleton.  Empty lists cannot 
be because they are mutable and each instance must be separately mutable.

 >>> x = 'a'; y = 'a'; x is y
True
 >>> x = (); y = (); x is y
True

> 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;

This is engineer talk.  From a mathematical point of view, the above is 
nonsense.  Math values are generally seen as timeless spaceless platonic 
values.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#84374

On Fri, Jan 23, 2015 at 4:46 AM, Andrew Robinson
<andrew3@r3dsolutions.com> wrote:
> Although, I have to laugh -- Verilog can syntheze a CPU -- implement memory
> -- and then load a program and run python on the virtual machine.   When the
> pentium was first developed, I watched as Intel actually booted up MS-DOS
> under using Xilinx chips to run the verilog program's output they could
> physically run anything a pentium processor could run.  That's *IS* what I
> consider "general purpose".

Turing-complete and "general purpose" are not the same. Would you
write a web application or a banking system in Verilog? Using Verilog
to host a virtual machine that runs such a program written in some
other language doesn't count; the actual application is still written
in that other language. You could implement the same Pentium virtual
machine in Brainf*** if you chose, but it will still be an esoteric
language, not a general-purpose one.

> But you're sort of confounding my need for type information in my new class
> as a way to advertise compatability with bool, with subclassing -- which is
> only one way that I was exploring to get the 'type' name attached to the new
> object;  That's a mistake that D'Aprano seems to be repetitively making as
> well.

No, I'm just responding specifically to the complaint you've been
making about not being able to subclass bool.

> C++ *DOES* allow the necessary kind of type checking and subclassing for
> what I need to do in spite of not having a subclass mechanism built into the
> language for base types; eg: C++ allows a semantic subclass to be
> constructed which can be typecast to a bool for compatibility, but otherwise
> presents extra data and the type the enhanced object reports is irrelevant.
> As I've mentioned before, people can do object oriented programming in C,
> So, to satisfy your curiosity -- I'll show you a mixed C/C++ example, where
> I make a semantic subclass that has five values AllFalse, PartFalse,
> Uncertain, PartTrue, True ; and these five values will have a typeid() of
> bool and be 100% compatible with legacy C++ bool; but upon request, they
> these 'bool' types will re-cast into a semantic subtype that provides
> additional certainty data.
>
> See the program at end of e-mail.  It compiles with gcc 4.8.2 with no
> warnings;  g++ filename.cc ; ./a.out

I'm not convinced this is generally safe. Unaware client code that
uses these values will lose the certainty values, even if the values
are later passed back into aware code.

const bool& is_p_equal_np() {
    return Uncertain;
}

void some_other_sbool_aware_code(const SBool& value) {
    if (SBool(PartFalse) < value) {
        cout << "Success: value is greater than PartFalse" << endl;
    } else {
        cout << "Failure: value is not greater than PartFalse" << endl;
    }
}

void some_sbool_unaware_code() {
    bool uncertainty = is_p_equal_np();
    some_other_sbool_aware_code(uncertainty);
}

Calling some_sbool_unaware_code() prints the Failure message because
the bool reference gets lost, and the typecast to SBool in
some_other_sbool_aware_code consequently results in AllFalse.

To the extent that this does work, it seems to be based on pointer
arithmetic, which is intentionally and explicitly something that
Python doesn't support. If Python had the means to distinguish name
bindings, then I see no other reason the same approach couldn't work.

> 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; For, singletons style programming is not justified by the
> number of values an object has in reality -- 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.

Writing down the word true multiple times doesn't create multiple
"instances" of the mathematical true. Mathematically, they're all the
same platonic object.

> As far a subtyping goes; The very fact that Guido used subtyping to create
> bool in the first place (subtype of int), precludes any real claim that bool
> should not itself be subclassable just because bools only have two values;
> I mean, seriously --  Guido's 'strict' Bool is already an impure form of OOP
> that is borderline hypocrisy, as it can '+' to 2 or 3... and many other
> things;  and worse I've just come across a couple of papers which suggest
> that Guido doesn't like subclassing when Composite object structures could
> be used instead to replace the subclass 'is' relationship with a 'has a'
> relationship.  So -- if that's the case, why isn't bool a composite to begin
> with ?  eg: Guido's programming guides must be read with a caveat 'do what
> Guido says and not what Guido does' ?!

bool is a subclass of int for backward compatibility. The bool type
wasn't added to Python until version 2.3. Before that, Python used 0
and 1 (hence why the __bool__ method is named __nonzero__ in 2.x).
Because bool subclasses int, it still does; it just has a more
specific type and names for them as well.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web