homepage

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.