CC @vstinner

I decided to use alternative approach, ignoring errno, as proposed in #156145. This is in a separate commit and can be easily reverted.

Edit: this will benefit from new private API in #156694. So, I would appreciate if that pr will be reviewed/merged first.

This breaks cmath.polar() for an underflowing atan2():

>>> import cmath
>>> cmath.polar(complex(1e300, 1e-320))
Traceback (most recent call last):
  ...
OverflowError: math range error

atan2(1e-320, 1e300) underflows and sets errno to ERANGE. Currently _Py_c_abs() resets it to 0, so cmath_polar_impl() does not see it. cmath.phase() fails this way already -- gh-153144.

@serhiy-storchaka, are you suggesting (1) reversion of errno = 0 stuff or (2) you are ok with moving errno = 0 down in cmath_polar_impl()?

I understand that this change fix a bug in math.isnan() if errno is non-zero.

It fixes abs(complex(nan)), when errno was set.

Would it make sense to backport the fix to 3.13-3.15 branches, without the C API change?

Looks to be a very minor issue. Though, I can revert all C-API changes for a separate PR.

Looks to be a very minor issue. Though, I can revert all C-API changes for a separate PR.

Oh no, there is no need to revert C API changes in this PR.

Merged, thanks for the fix, and sorry for being picky on documenting the change :-D

@skirpichev: So what do you think of backporting the fix to Python 3.15 and older without changing _Py_c_abs() API?

For the backport, I suppose that we can do simply what the issue title says:

"complex_abs() should call _Py_c_abs() with errno=0 set": just set errno to 0 before calling _Py_c_abs().

GH-157341 is a backport of this pull request to the 3.15 branch.

So what do you think of backporting the fix to Python 3.15 and older

Should I create backports for <3.15 by hand?

Thanks for the backport to 3.15. Once it will be merged (after Python 3.15.0 final release), automated backported to 3.13 and 3.14 will be created. No need to backport again by hand.