Guido van Rossum added the comment: > > 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. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com