-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-61103: support double complex (_Complex) type in ctypes #120894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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>
Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>
Misc/NEWS.d/next/Library/2024-06-23-07-23-08.gh-issue-61103.ca_U_l.rst
Outdated
Show resolved
Hide resolved
I'd prefer having a separate PR because we might need aliases in case
I think it might be indeed a good alternative, because otherwise you need to find good 1-char names for
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>
45f8544
to
013765e
Compare
013765e
to
f9c709c
Compare
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. |
* add configure test for _Complex type * define HAVE_C_COMPLEX * move workarounds for buggy implementations to Module/_complex.h
!buildbot s390x SLES |
Well, one failure seems to be related: 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 |
!buildbot AMD64 Fedora Rawhide PR |
Oh, Rawhide failure is unrelated: "No space left on device". |
!buildbot PPC64LE CentOS9 PR |
!buildbot PPC64LE Fedora Stable Clang PR |
Thanks @skirpichev, I merged your PR. I checked remaining buildbot failures: they are unrelated to the change. @skirpichev: @erlend-aasland has concerns about relative |
Thanks for reviews and patience.
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 |
…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>
…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>
…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>
Example:
ctypes.c_double_complex
is available only if compiler does support complex arithmetic (Annex G).📚 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?c_double_complex._type_
chosen to be "C". Maybe we should allow instead multiple chars to specify types (e.g. "Cd" fordouble complex
)?