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

Groups > comp.lang.python > #83275 > 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-06 18:20 -0800

#83275 — Re: Comparisons and sorting of a numeric class....

On 01/06/2015 05:35 AM, Chris Angelico wrote:
> On Wed, Jan 7, 2015 at 12:30 AM, Andrew Robinson
> <andrew3@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...

[toc] | [standalone]

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

csiph-web