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 jyasskin
Recipients facundobatista, gvanrossum, jyasskin, mark.dickinson, rhettinger
Date 2008-02-09.05:46:46
SpamBayes Score 0.0508665
Marked as misclassified No
Message-id <>
I figured I'd time the difference before we change the code:

$ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)'
1000000 loops, best of 3: 0.696 usec per loop
$ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)'
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,
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.
Date User Action Args
2008-02-09 05:46:54jyasskinsetspambayes_score: 0.0508665 -> 0.0508665
recipients: + jyasskin, gvanrossum, rhettinger, facundobatista, mark.dickinson
2008-02-09 05:46:54jyasskinsetspambayes_score: 0.0508665 -> 0.0508665
messageid: <>
2008-02-09 05:46:48jyasskinlinkissue1682 messages
2008-02-09 05:46:46jyasskincreate