Jeffrey Yasskin added the comment: I figured I'd time the difference before we change the code:
$ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)' 'r.numerator' 1000000 loops, best of 3: 0.696 usec per loop $ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)' 'r._numerator' 10000000 loops, best of 3: 0.155 usec per loop $ ./python.exe -m timeit -s '(3).numerator' 10000000 loops, best of 3: 0.0324 usec per loop $ ./python.exe -m timeit -s '(3L).numerator' 10000000 loops, best of 3: 0.0356 usec per loop $ ./python.exe -m timeit -s 'from rational import Rational' 'Rational(3, 1)' 10000 loops, best of 3: 80.4 usec per loop $ ./python.exe -m timeit -s 'from rational import Rational; r=Rational(3, 1)' 'isinstance(r, Rational)' 100000 loops, best of 3: 10.6 usec per loop So every time we change .numerator to ._numerator we save half a microsecond. If we construct a new Rational from the result, that's totally drowned out by the Rational() call. Even checking whether we're looking at a Rational costs 20 times as much as the difference, although that can probably be optimized. I think this means that we shouldn't bother changing the arithmetic methods since it makes the code more complicated, but changing unary methods, especially ones that don't return Rationals, can't hurt. __________________________________ 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
