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.

classification
Title: Fraction('1e6') should be valid.
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: jyasskin, mark.dickinson, rhettinger
Priority: normal Keywords: patch

Created on 2009-04-22 10:04 by mark.dickinson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
fraction_from_exp.patch mark.dickinson, 2009-04-22 10:04
fraction_of_fractions.patch mark.dickinson, 2009-04-22 20:57
fraction_of_fractions2.patch mark.dickinson, 2009-04-22 21:41
Messages (8)
msg86283 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-11 14:56:48adminsetgithub: 50062
2009-04-24 14:09:18mark.dickinsonsetstatus: open -> closed
resolution: accepted
messages: + msg86410

stage: patch review -> resolved
2009-04-22 21:41:35mark.dickinsonsetfiles: + fraction_of_fractions2.patch

messages: + msg86339
2009-04-22 20:57:25mark.dickinsonsetfiles: + fraction_of_fractions.patch

messages: + msg86333
stage: needs patch -> patch review
2009-04-22 18:20:52mark.dickinsonsetstage: patch review -> needs patch
2009-04-22 18:20:36mark.dickinsonsetmessages: + msg86311
2009-04-22 16:02:24jyasskinsetmessages: + msg86302
2009-04-22 12:00:28mark.dickinsonsetmessages: + msg86288
2009-04-22 11:24:33rhettingersetnosy: + rhettinger
messages: + msg86286
2009-04-22 10:04:25mark.dickinsoncreate