gh-155526: correct errno handling in complex_abs()

[skirpichev]

• Issue: complex_abs() should call _Py_c_abs() with errno=0 set #155526

[skirpichev]

CC @vstinner

[skirpichev]

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.

[serhiy-storchaka]

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.

[skirpichev]

@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()?

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #34490277 | 📁 Comparing 38eac1f against main (f8f8c30)

  🔍 Preview build  

8 files changed · ± 8 modified

± Modified

• c-api/complex.html
• howto/logging-cookbook.html
• howto/mro.html
• library/curses.html
• library/logging.config.html
• reference/datamodel.html
• whatsnew/3.16.html
• whatsnew/changelog.html

[skirpichev]

Just FYI, GH code search has no hits for _Py_c_abs(), except for CPython forks. Victor did PyPI search before for all soft-deprecated complex C-API: one hit for _Py_c_pow() in Numba.

[vstinner]

The change mostly LGTM. I just have a last request about the change documentation.

I understand that this change fix a bug in math.isnan() if errno is non-zero. Would it make sense to backport the fix to 3.13-3.15 branches, without the C API change?

[vstinner]

I applied the 2 @hpkfft's suggestions (fixing typos).

[skirpichev]

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.

[vstinner]

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.