That's nice, Ethan, especially in that it saves having to explicitly find and
list all the methods being covered. It's perhaps not quite so critical for a
Fraction-based class, since the set of methods to be covered is fairly well
contained, but that's not always going to be the case.
The appro
On Saturday, March 13, 2010 9:03:36 AM UTC-8, Jonathan Lundell wrote:
> I've got a subclass of fractions.Fraction called Value; it's a mostly
> trivial class, except that it overrides __eq__ to mean 'nearly equal'.
> However, since Fraction's operations result in a Fraction, not a
> Value, I end up
On Mar 17, 5:12 pm, Steven D'Aprano
wrote:
> On Mon, 15 Mar 2010 16:34:35 -0700,JLundellwrote:
> > It's also unfortunate that Python doesn't have an approximately-equal
> > operator; it'd come in handy for floating-point applications while
> > preserving hash. If only there were a ~= or ≈ operator
On Mar 16, 8:06 am, Robert Kern wrote:
> On 2010-03-16 07:35 AM, Dave Angel wrote:
>
>
>
>
>
>
>
> > Carl Banks wrote:
> >> On Mar 15, 4:34 pm, JLundell wrote:
> >>> It's also unfortunate that Python doesn't have an approximatel
On Mar 13, 1:26 pm, Carl Banks wrote:
> It's a tad unfortunately Python doesn't make this easier. If I had to
> do it more than once I'd probably write a mixin to do it:
>
> class ArithmeticSelfCastMixin(object):
> def __add__(self,other):
> return
> self.__class__(super(ArithmeticSel
On Mar 13, 9:37 am, Jack Diederich wrote:
> If Fraction.__add__ returns a new object but the subclass Value is
> compatible (as I would except since it is a sublcass) then just change
> all references in Franction.__add__ to be more generic, ex/
>
> class Franction():
> def __add__(self, other):
I've got a subclass of fractions.Fraction called Value; it's a mostly
trivial class, except that it overrides __eq__ to mean 'nearly equal'.
However, since Fraction's operations result in a Fraction, not a
Value, I end up with stuff like this:
x = Value(1) + Value(2)
where x is now a Fraction, no
