Mark Dickinson added the comment: 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 :) __________________________________ 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
