| msg86283 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
Date: 2009-04-22 10:04 |
| When the Fractions module was first added to Python, it was decided that when constructing from a string, decimal strings should be allowed, but not those including an exponent. For example, Fraction('1.1') is currently valid, but Fraction('1.1e6') is not. I think exponents should be permitted, for a couple of reasons: (1) consistency: there's a clearly-defined notion of a numeric string of the form ([sign] integer_part [fractional_part] [exponent]); the float and Decimal constructors both accept all numeric strings. Fraction currently accepts some, but not all of these. (2) Easy interactions with floats: with this addition, a Fraction can always be constructed from the str() or repr() of a finite float or finite Decimal; without it, only some of those strings can be converted. (3) Ease of parsing files containing numeric strings. (4) It's a very simple change! See attached patch. Jeffrey, any thoughts? |
|
|
| msg86286 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-04-22 11:24 |
| Also, it would be nice if the Fraction constructor accepted both a numerator and denominator that we also fractions. This came up in a demonstration of continued fractions and it bombed when the denominator was not allowed to be a Fraction itself. The meaning is well-defined and it is also a simple change. |
|
|
| msg86288 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-22 12:00 |
| > Also, it would be nice if the Fraction constructor accepted both a > numerator and denominator that we also fractions. This makes sense to me. It reminds me of the way that complex(real, imag) allows real and imag to be complex numbers, and does the 'right thing'. |
|
|
| msg86302 - (view) |
Author: Jeffrey Yasskin (jyasskin) * |
Date: 2009-04-22 16:02 |
| Sounds good to me. I can't find any real objections to the new format in issue 1682, just me complaining that it might be feature creep. |
|
|
| msg86311 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-22 18:20 |
| Fraction constructor modified to accept all numeric strings in r71806 (py3k), 71808 (trunk). Leaving this open for Raymond's suggested change. |
|
|
| msg86333 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-22 20:57 |
| Here's a patch for making Fraction(3, Fraction(4, 5)) valid. It's against the trunk. |
|
|
| msg86339 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-22 21:41 |
| Hmm. That patch isn't quite right, in at least two respects - if the single-argument constructor is using LBYL (i.e., an explicit isinstance(x, Rational), then the two-argument constructor should too. - the zero-division check should come *after* the type check; that is, Rational(1, 0j) should raise TypeError rather than ZeroDivisionError. Here's an updated version, that also makes the default second argument None rather than 1 and uses an 'is None' instead of '== 1' to determine number of arguments; this means that Fraction(3, 1.0) is no longer valid. |
|
|
| msg86410 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-24 14:09 |
| Applied in r71832 (trunk), r71834 (py3k). One nice aspect of this change is that "Fraction(a, b)" is now a safe alternative to "a/b" in places where a and b might be either Fractions or integers. |
|
|