Fraction(float) doesn't behave like Fraction(float, 1)

[retooth2]

Bug report

Bug description:

Hi, I discovered the following bug in the init of the Fraction object:

from fractions import Fraction

print(Fraction(0.5) == Fraction(0.5, 1))

Expected Output:

True

Actual Output:

*** TypeError: both arguments should be Rational instances

Similarly:

from fractions import Fraction

print(Fraction(0.5, 0.5) == Fraction(1))

Expected Output:

True

Actual Output:

*** TypeError: both arguments should be Rational instances

Tested on

Python 3.11.7
Python 3.13.4

CPython versions tested on:

3.11, 3.13

Operating systems tested on:

macOS

[terryjreedy]

A float is not a numbers.Rational.

issubclass(float, num.Rational)
                    
False

Fraction(n, m) requires that both n and m be a numbers.Rational. Therefore Franction(.5, <whatever)) raises TypeError: both arguments should be Rational instances. The comparisons swallow that exception and then fail with the message displayed above.

[retooth2]

Sorry, this seems inconsistent to me.

Why then does

Fraction(0.5)

work just fine and results in the expected

Fraction(1, 2)

Even this is fine:

>>> from math import pi
>>> Fraction(pi)
Fraction(884279719003555, 281474976710656)

Either floats should be considered (possibly) irrational and forbidden as types for Fraction or they should be considered rational (which imho they are by definition of their finite nature), but then my above observation is clearly bug.

[gvanrossum]

The function is overloaded. It either takes one float or two rationals (integers, Fractions, etc., but not floats).

[retooth2]

Is there a technical/structural reason for this?

I would argue, if

Fraction(0.5)

is well-defined, so is:

Fraction(0.5, 0.5)

I agree however it is not a bug then.

[gvanrossum]

It's by design. The two overloads do very different things: Fraction(0.5) converts the float to a fraction (giving interesting answers for e.g. Fraction(1/3), whereas Fraction(i, j) computes the GCD and then produces a normalized Fraction object directly from those values. Fraction() is meant to use as a "cast", similar to float(i) or str(i).

[retooth2]

Ah ok! Seeing Fraction(float) as a cast makes sense. Thanks for taking the time to explain.
Out of curiosity: Why is float not considered a numbers.Rational? Is it because of math.pi, etc?

[gvanrossum]

You're welcome.

While float technically has a finite set of values (about 2**64) it is conceptually used to represent a Real. Just like math.pi etc. are of necessity approximations, they are the best approximation for the transcendental number implied by their name.

[retooth2]

Thanks for the explanation. It would be really great to have a proper Real representation as a builtin type in some future python version. I currently have to import 71MB of sympy as a dependency for my music library just to have a precise representation of $2^{\frac{x}{12}}$ for equal temperaments.

[gvanrossum]

Well, we don't really want to add 71MB to the standard library either. :-)

[retooth2]

Understandable ;) I had only my couple special cases in mind, but the more I think about doing a "proper" implementation of the Reals the more I realize this would amount to reimplementing sympy (or at least mpmath). Anyway: Thanks for the nice chat. Keep up the good work!