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

Groups > comp.lang.python > #83276

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

Show key headers only | View raw

On Wed, Jan 7, 2015 at 1:20 PM, Andrew Robinson
<andrew3@r3dsolutions.com> wrote:
> 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.

If you use a dedicated function instead of methods, that function can
be written to take any combination of float and pseudo-float.

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

Thing is, you're not fulfilling bool's contract, so it's better to not
subclass, and just make your new type always falsy. If your users are
type-checking bools, you might just have to let it break, and tell
them not to do that.

ChrisA

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Comparisons and sorting of a numeric class.... Chris Angelico <rosuav@gmail.com> - 2015-01-07 13:31 +1100

csiph-web