Author gvanrossum
Recipients facundobatista, gvanrossum, jyasskin, mark.dickinson, rhettinger
Date 2008-02-08.01:23:33
SpamBayes Score 0.0110428
Marked as misclassified No
Message-id <ca471dc20802071723m4bf23b3buacd0522b4dd48558@mail.gmail.com>
In-reply-to <1202432586.94.0.930346564219.issue1682@psf.upfronthosting.co.za>
Content
> > I have one minor nit on the current rational.py code: all internal
> > accesses to the numerator and denominator should use self._numerator
> > and self._denominator -- going through the properties makes it *much*
> > slower. Remember that Python function/method calls are slow, and never
> > optimized away. :-)
>
> This isn't quite as simple as doing s/.numerator/._numerator, since the
> current code makes use of the fact that the int and long types also
> implement .numerator and .denominator.

Well, but *self.numerator* certainly doesn't need to worry about self
being an int or long. :-)

> Can we follow the approach that Decimal takes:  convert subclasses of
> int and long to Rational before operating?  At first sight it seems
> possible that this might actually slow down code that does a lot of
> mixed-mode int/long + Rational arithmetic, but I think this is unlikely.
> I'll implement this unless there are objections.

It had never occurred to me to do it otherwise. ;-)

> I'm also wondering what the policy should be on return types:  if a and
> b are instances of a subclass of Rational, should a+b have return type
> Rational, or return type equal to that of a and b?  Current behaviour of
> various builtin types and Decimal suggests that a Rational should be
> returned.

Correct -- the thing is that you can't know the signature of the
subclass's constructor so you can't very well blindly call that.
History
Date User Action Args
2008-02-08 01:23:34gvanrossumsetspambayes_score: 0.0110428 -> 0.0110428
recipients: + gvanrossum, rhettinger, facundobatista, mark.dickinson, jyasskin
2008-02-08 01:23:33gvanrossumlinkissue1682 messages
2008-02-08 01:23:33gvanrossumcreate