On Wed, Jan 7, 2015 at 1:20 PM, Andrew Robinson <andr...@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 -- https://mail.python.org/mailman/listinfo/python-list
