Fraction('1e6') should be valid.

[mdickinson]

BPO	5812
Nosy	@rhettinger, @mdickinson
Files	fraction_from_exp.patch fraction_of_fractions.patch fraction_of_fractions2.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/mdickinson' closed_at = created_at = labels = ['type-feature', 'library'] title = "Fraction('1e6') should be valid." updated_at = user = 'https://github.com/mdickinson' ``` bugs.python.org fields: ```python activity = actor = 'mark.dickinson' assignee = 'mark.dickinson' closed = True closed_date = closer = 'mark.dickinson' components = ['Library (Lib)'] creation = creator = 'mark.dickinson' dependencies = [] files = ['13735', '13739', '13742'] hgrepos = [] issue_num = 5812 keywords = ['patch'] message_count = 8.0 messages = ['86283', '86286', '86288', '86302', '86311', '86333', '86339', '86410'] nosy_count = 3.0 nosy_names = ['rhettinger', 'mark.dickinson', 'jyasskin'] pr_nums = [] priority = 'normal' resolution = 'accepted' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue5812' versions = ['Python 3.1', 'Python 2.7'] ```

[mdickinson]

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?

[rhettinger]

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.

[mdickinson]

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'.

[5969680d-a065-4b5f-9706-8216692d995a]

Sounds good to me. I can't find any real objections to the new format in bpo-1682, just me complaining that it might be feature creep.

[mdickinson]

Fraction constructor modified to accept all numeric strings in r71806 (py3k), 71808 (trunk).

Leaving this open for Raymond's suggested change.

[mdickinson]

Here's a patch for making Fraction(3, Fraction(4, 5)) valid. It's against the trunk.

[mdickinson]

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.

[mdickinson]

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.