gh-61103: support double complex (_Complex) type in ctypes

[skirpichev]

Example:

>>> import ctypes >>> libm = ctypes.CDLL('libm.so.6') >>> libm.clog.argtypes = [ctypes.c_double_complex] >>> libm.clog.restype = ctypes.c_double_complex >>> libm.clog(1+1j) (0.34657359027997264+0.7853981633974483j)

ctypes.c_double_complex is available only if compiler does support complex arithmetic (Annex G).

• Issue: Add support for C99 complex type (_Complex) as ctypes.c_complex #61103

---

📚 Documentation preview 📚: https://cpython-previews--120894.org.readthedocs.build/

---

---

Notes for reviewers:

• It seems, most compilers implement this optional feature of C11+. (Though neither does this correctly.) Maybe we should require one?
• only one complex type was added; if this looks good - I can add the rest (float complex and long double complex) in this pr or in other.
• c_double_complex._type_ chosen to be "C". Maybe we should allow instead multiple chars to specify types (e.g. "Cd" for double complex)?
• this pr doesn't include changes in the struct module. Perhaps, I should add support for complex type here as well?
• if test_complex_round_trip() does make sense for reviewers, here is a simple refactoring to avoid adding yet another assertFloatsAreIdentical() helper: gh-121039: add Floats/ComplexesAreIdenticalMixin to test.support.testcase #121071

[picnixz]

I can add the rest (float complex and long double complex) in this pr or in other.

I'd prefer having a separate PR because we might need aliases in case sizeof(long double) == sizeof(double) (the same technique that is used for long long and long IIRC)

c_double_complex.type chosen to be "C". Maybe we should allow instead multiple chars to specify types (e.g. "Cd" for double complex)?

I think it might be indeed a good alternative, because otherwise you need to find good 1-char names for float complex and long double complex in the future, but I think Cf, Cd and Cl (or Cq for quad-precision) are good enough. But for that we need to update the fielddesc structure with an additional field that would be a "modifier" of some sort or allow the "code" to be more than just a single character.

this pr doesn't include changes in the struct module. Perhaps, I should add support for complex type here as well?

I'd say in a separate PR since there is a translation of ctypes format to PEP 3118 names (where complex numbers are represented by 'Z').

[nineteendo]

Use a force-push only to fix typo's or revert a merge.

[skirpichev]

Use a force-push only to fix typo's or revert a merge.

Thank you for advice. Usually I don't do this. I hope this time force-push was OK, as it's restricted to unreviewed commits.

[nineteendo]

It's less bad if no-one commented on those commits, but it's still more work to figure out what you changed.
It's also more distracting than a regular commit. (also, you don't need to quote the whole previous message)

[vstinner]

!buildbot s390x SLES

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit e9cab4a 🤖

The command will test the builders whose names match following regular expression: s390x SLES

The builders matched are:

• s390x SLES PR

[skirpichev]

Well, one failure seems to be related:
https://buildbot.python.org/all/#/builders/1262/builds/13/steps/3/logs/stdio
Edit (similar one):
https://buildbot.python.org/all/#/builders/855/builds/119

Looking on the libffi sources, it seems that FFI_TYPE_COMPLEX is available unconditionally, even if platform doesn't support interfaces to _Complex (for sparc it works since v3.3). We should check FFI_TARGET_HAS_COMPLEX_TYPE instead.

I'll update PR when build finish.

[vstinner]

!buildbot AMD64 Fedora Rawhide PR

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit 6d5bf66 🤖

The command will test the builders whose names match following regular expression: AMD64 Fedora Rawhide PR

The builders matched are:

• AMD64 Fedora Rawhide PR

[vstinner]

!buildbot AMD64 Fedora Rawhide PR

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit 6d5bf66 🤖

The command will test the builders whose names match following regular expression: AMD64 Fedora Rawhide PR

The builders matched are:

• AMD64 Fedora Rawhide PR

[vstinner]

Oh, Rawhide failure is unrelated: "No space left on device".

[vstinner]

!buildbot PPC64LE CentOS9 PR

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit 6d5bf66 🤖

The command will test the builders whose names match following regular expression: PPC64LE CentOS9 PR

The builders matched are:

• PPC64LE CentOS9 PR

[vstinner]

!buildbot PPC64LE Fedora Stable Clang PR

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit 6d5bf66 🤖

The command will test the builders whose names match following regular expression: PPC64LE Fedora Stable Clang PR

The builders matched are:

• PPC64LE Fedora Stable Clang PR

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit 6d5bf66 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[vstinner]

Thanks @skirpichev, I merged your PR.

I checked remaining buildbot failures: they are unrelated to the change.

@skirpichev: @erlend-aasland has concerns about relative #include.

[skirpichev]

Thanks for reviews and patience.

@erlend-aasland has concerns about relative #include.

Yep, here; I'll open an issue (I think that build failures in this pr already don't need this;)). There are other includes, besides _math.h.