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

skirpichev · 2024-06-23T05:11:55Z

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>

picnixz · 2024-06-23T11:00:37Z

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>

nineteendo · 2024-06-23T17:46:25Z

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

skirpichev · 2024-06-23T18:03:07Z

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 · 2024-06-23T18:10:01Z

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

skirpichev · 2024-06-30T11:07:16Z

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 · 2024-06-30T17:47:02Z

!buildbot AMD64 Fedora Rawhide PR

bedevere-bot · 2024-06-30T17:47:04Z

🤖 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 · 2024-06-30T17:49:10Z

!buildbot AMD64 Fedora Rawhide PR

bedevere-bot · 2024-06-30T17:49:15Z

🤖 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 · 2024-06-30T17:49:36Z

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

vstinner · 2024-06-30T17:50:45Z

!buildbot PPC64LE CentOS9 PR

bedevere-bot · 2024-06-30T17:50:48Z

🤖 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 · 2024-06-30T18:21:38Z

!buildbot PPC64LE Fedora Stable Clang PR

bedevere-bot · 2024-06-30T18:21:41Z

🤖 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 · 2024-07-01T07:21:26Z

🤖 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 · 2024-07-01T08:56:18Z

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 · 2024-07-01T10:17:08Z

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.

…hon#120894) 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) ``` Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Victor Stinner <vstinner@python.org>

bedevere-appBot mentioned this pull request Jun 23, 2024
Add support for C99 complex type (_Complex) as ctypes.c_complex #61103
Closed

bedevere-appBot added the awaiting review label Jun 23, 2024

skirpichev added 3 commits June 23, 2024 08:15

+ ifdef
b402300

+ fix rst formatting
ad39e6d

+ CMPLX
fd9135b

nineteendo reviewed Jun 23, 2024
View reviewed changes

Comment threadLib/test/test_ctypes/test_libc.py Outdated
Comment threadLib/test/test_ctypes/test_libc.py

skirpichevand others added 2 commits June 23, 2024 09:00

Apply suggestions from code review
c296fb3
Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>

+ support _Complex in c-analyzer
7453ca5

skirpichev requested a review from ericsnowcurrently as a code owner June 23, 2024 07:12

skirpichev added 4 commits June 23, 2024 10:47

+1
e444c9c

expand docs
2e90643

drop ctypes.__STDC_IEC_559_COMPLEX__
32ffacf

And more tests, finally)
9163950

skirpichev requested a review from nineteendo June 23, 2024 09:36

nineteendo reviewed Jun 23, 2024
View reviewed changes

Comment threadDoc/library/ctypes.rst Outdated
Comment threadDoc/library/ctypes.rst
Comment threadDoc/library/ctypes.rst

Apply suggestions from code review
bf81682
Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>

picnixz reviewed Jun 23, 2024
View reviewed changes

skirpichevand others added 2 commits June 23, 2024 14:47

Apply suggestions from code review
af2fdce
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>

+ allow _Complex specifier before float/double/etc
6d9d5ab

skirpichev force-pushed the ctypes-c_complex-61103 branch from 45f8544 to 013765eCompare June 23, 2024 13:07

+ comment on clang workaround
f9c709c

skirpichev force-pushed the ctypes-c_complex-61103 branch from 013765e to f9c709cCompare June 23, 2024 17:33

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

skirpichev requested review from corona10 and erlend-aasland as code owners June 24, 2024 03:47

sed: FFI_TYPE_COMPLEX -> FFI_TARGET_HAS_COMPLEX_TYPE
6d5bf66

vstinner added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 1, 2024

bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 1, 2024

vstinner merged commit 6988ff0 into python:mainJul 1, 2024

bedevere-appBot removed the awaiting merge label Jul 1, 2024

skirpichev deleted the ctypes-c_complex-61103 branch July 1, 2024 09:56

skirpichev mentioned this pull request Jul 1, 2024
Should we allow relative includes? (i.e. #include "../_ssl.h") #121223
Closed

skirpichev mentioned this pull request Jul 10, 2024
gh-121039: add Floats/ComplexesAreIdenticalMixin to test.support.testcase #121071
Merged

This was referenced Oct 7, 2024
gh-121249: Support _Complex types in the struct module #121613
Merged
CTypes test failed, complex double problem #125206
Closed
gh-125206: Bug in ctypes with old libffi is fixed #125322
Merged

skirpichev mentioned this pull request Jan 22, 2025
implement PEP 3118 struct changes #47382
Open

skirpichev mentioned this pull request Apr 13, 2026
gh-146151: support for complex arrays in the array module #146237
Merged

freakboy3742 mentioned this pull request Jun 15, 2026
gh-151422: Don't link libffi into _ctypes_test.so #151423
Merged

Uh oh!

Uh oh!

Conversation

skirpichev commented Jun 23, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

picnixz commented Jun 23, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nineteendo commented Jun 23, 2024

Uh oh!

skirpichev commented Jun 23, 2024

Uh oh!

nineteendo commented Jun 23, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skirpichev commented Jun 30, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vstinner commented Jun 30, 2024

Uh oh!

bedevere-bot commented Jun 30, 2024

Uh oh!

vstinner commented Jun 30, 2024

Uh oh!

bedevere-bot commented Jun 30, 2024

Uh oh!

vstinner commented Jun 30, 2024

Uh oh!

vstinner commented Jun 30, 2024

Uh oh!

bedevere-bot commented Jun 30, 2024

Uh oh!

vstinner commented Jun 30, 2024

Uh oh!

bedevere-bot commented Jun 30, 2024

Uh oh!

bedevere-bot commented Jul 1, 2024

Uh oh!

vstinner commented Jul 1, 2024

Uh oh!

skirpichev commented Jul 1, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

skirpichev commented Jun 23, 2024•
edited
Loading

picnixz commented Jun 23, 2024•
edited
Loading

nineteendo commented Jun 23, 2024•
edited
Loading

skirpichev commented Jun 30, 2024•
edited
Loading