Comparisons and sorting of a numeric class....

[Andrew Robinson]

On 01/06/2015 05:35 AM, Chris Angelico wrote:
> On Wed, Jan 7, 2015 at 12:30 AM, Andrew Robinson
> <andrew3 at r3dsolutions.com> wrote:
>> Why this is so important to Guido, I don't know ... but it's making it VERY
>> difficult to add named aliases of False which will still be detected as
>> False and type-checkable as a bool.  If my objects don't type check right --
>> they will likely break some people's legacy code...  and I really don't even
>> care to create a new instance of the bool object in memory which is what
>> Guido seems worried about, rather I'm really only after the ability to
>> detect the subclass wrapper name as distinct from bool False or bool True
>> with the 'is' operator.  If there were a way to get the typecheck to match,
>> I wouldn't mind making a totally separate class which returned the False
>> instance; eg: something like an example I modified from searching on the
>> web:
> Okay, so why not just go with your own class, and deal with the
> question of the type check? Simple solution: Instead of fiddling with
> __gt__/__lt__, create your own method, and use your own comparison
> function to sort these things.
>
> ChrisA
Because defining a bunch of special methods defeats the very purpose of 
making my class compatible with float variables.
eg: No legacy code would work...

I know (belatedly) that am going to have to define my own class.
That's pretty much a given, but I want to do it in a way which requires 
my users to make very few changes to their traditional floating point 
algorithms and code.

The type check issue is mostly about compatability in the first place ; 
eg: users typecheck either unintentionally -- (novices syndrome) -- or 
because they need all the capabilities of a given type, and the only 
simple way to find out if they are all there are there is to typecheck.  
eg: That's the whole point of subclassing bool ... to let the user know 
they have at their disposal (in a portable, simple way) all the features 
of the base type.

Well, if I make a new object -- type checking is pointless.   No user 
thinking they were coding for floating point in the past would know that 
my new return type is totally compatible with bool.  They would have to 
have written individual tests for the existence of every method in bool, 
and why would they be crazy enough to do that? It's a lot of work for 
nothing...