gh-61103: support double complex (_Complex) type in ctypes by skirpichev · Pull Request #120894 · python/cpython · GitHub

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

Example: ```pycon >>> import ctypes >>> ctypes.__STDC_IEC_559_COMPLEX__ 1 >>> 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.__STDC_IEC_559_COMPLEX__`` is ``0`` if compiler doesn't support complex arithmetic (Annex G).

Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>

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').

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>

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

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.

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)

* add configure test for _Complex type * define HAVE_C_COMPLEX * move workarounds for buggy implementations to Module/_complex.h

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.

!buildbot AMD64 Fedora Rawhide PR