complex(x) ignores an overridden __float__ of a float subclass since 3.14 #161926

Bug report

Bug description

Since 3.14, the single-argument form complex(x) no longer calls x.__float__() when x is an instance of a float subclass that overrides __float__. The two-argument form, the keyword form and float(x) still call it, and 3.13 called it in every form.

class F(float):
    def __float__(self):
        return 42.0

x = F(1.0)
print(complex(x))        # 3.13: (42+0j)   3.14+: (1+0j)
print(complex(x, 0))     # (42+0j) on every version
print(complex(real=x))   # (42+0j) on every version
print(float(x))          # 42.0 on every version

Because __float__ is no longer called, an exception it raises no longer propagates either: with def __float__(self): raise Exception, complex(x) raises on 3.13 and returns (1+0j) on 3.14.

The documentation describes the single-argument form of complex() in the same words it uses for float(): "For a general Python object x, complex(x) delegates to x.__complex__(). If __complex__ is not defined then it falls back to __float__." float(x) calls the override, and complex(x) did too up to 3.13.

The new result is the one complex.from_number(x) and float.from_number(x) give. Those, like math.sqrt() and other C-level conversions, read the stored value of a float instance through PyFloat_AsDouble() and have never consulted the override. This report is only about the constructor, whose forms now disagree with each other and with float(x).

Cause

GH-119620 (gh-109218, ef01e95, first released in 3.14.0a1) split the constructor and added a single-argument path, actual_complex_new() in Objects/complexobject.c. That path converts a real argument with PyFloat_AsDouble(arg), which returns the value of any float instance directly (PyFloat_Check) without calling nb_float:

The two-argument path in complex_new_impl() keeps PyNumber_Float(r), which 3.13 used for every form and which calls nb_float unless the argument is an exact float:

The change is not mentioned in What's New in 3.14 or in the NEWS entry of gh-109218, and test_complex exercises __float__ only on a class that does not inherit from float (WithFloat), so no test covers a float subclass that overrides it.

Possible fix

Convert through PyNumber_Float() in the single-argument path as the two-argument path does, or, if the new behavior is intended, document that complex(x) does not consult __float__ of a float subclass.

CPython versions tested on:

3.14, 3.15, 3.16

Operating systems tested on:

Linux

Linked PRs

• gh-161926: Honor overridden __float__ in complex() #161949