Comparisons and sorting of a numeric class....
andrew3 at r3dsolutions.com
Wed Jan 7 03:20:09 CET 2015
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
> 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.
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
More information about the Python-list