Message59884
The latest version of rational.py looks good to me---nice work! (I haven't looked properly at
numbers.py or test_rational.py, yet. I do plan to, eventually.)
I do think it's important to be able to create Rational instances from strings: e.g., for
easy reading from and writing to files. But maybe I'm alone in this opinion. You say there's
more than one possible format---what other formats were you considering?
And since you pointed it out, I think Rational(Rational(a, b)) should work too.
There's also the not-entirely-insignificant matter of documentation :)
Other than that, I don't see why this shouldn't go in.
Other comments:
I have a weak preference for no parentheses on the str() of a Rational, but it's no big deal
either way.
I agree that equality and comparisons are messy. This seems almost inevitable: one obvious
cause is that the existing int <-> float comparisons already break the `numeric tower' model
(push both operands to the highest common type before operating). So I'm not sure there can
be an easy and elegant solution here :(
I like the name Rational for this class. Maybe change the name of numbers.Rational instead?
Postponing trim, approximate, from_decimal sounds fine to me.
Finally: the very first line of rational.py is, I think, no longer accurate. Please add your
name so everyone knows who to blame/credit/assign bug reports to :) |
|
Date |
User |
Action |
Args |
2008-01-14 01:45:49 | mark.dickinson | set | spambayes_score: 1.54494e-05 -> 1.5449397e-05 recipients:
+ mark.dickinson, gvanrossum, rhettinger, facundobatista, jyasskin |
2008-01-14 01:45:49 | mark.dickinson | set | spambayes_score: 1.54494e-05 -> 1.54494e-05 messageid: <1200275149.2.0.619514227841.issue1682@psf.upfronthosting.co.za> |
2008-01-14 01:45:48 | mark.dickinson | link | issue1682 messages |
2008-01-14 01:45:47 | mark.dickinson | create | |
|