This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients facundobatista, gvanrossum, jyasskin, mark.dickinson, rhettinger
Date 2008-02-08.01:03:05
SpamBayes Score 0.015785456
Marked as misclassified No
Message-id <1202432586.94.0.930346564219.issue1682@psf.upfronthosting.co.za>
In-reply-to
Content
from Guido:

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

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.

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.
History
Date User Action Args
2008-02-08 01:03:07mark.dickinsonsetspambayes_score: 0.0157855 -> 0.015785456
recipients: + mark.dickinson, gvanrossum, rhettinger, facundobatista, jyasskin
2008-02-08 01:03:07mark.dickinsonsetspambayes_score: 0.0157855 -> 0.0157855
messageid: <1202432586.94.0.930346564219.issue1682@psf.upfronthosting.co.za>
2008-02-08 01:03:06mark.dickinsonlinkissue1682 messages
2008-02-08 01:03:05mark.dickinsoncreate