Skip to content

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

Closed
#121248
Closed
Add support for C99 complex type (_Complex) as ctypes.c_complex#61103
#121248
Labels
topic-ctypestype-featureA feature request or enhancement

Description

@rutsky
rutsky
mannequin
opened on Jan 8, 2013
BPO 16899
Nosy @arigo, @amauryfa, @mdickinson, @meadori

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-01-08.22:06:03.435>
labels = ['ctypes', 'type-feature', '3.7']
title = 'Add support for C99 complex type (_Complex) as ctypes.c_complex'
updated_at = <Date 2018-07-04.15:01:25.648>
user = 'https://bugs.python.org/rutsky'

bugs.python.org fields:

activity = <Date 2018-07-04.15:01:25.648>
actor = 'arigo'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['ctypes']
creation = <Date 2013-01-08.22:06:03.435>
creator = 'rutsky'
dependencies = []
files = []
hgrepos = []
issue_num = 16899
keywords = []
message_count = 10.0
messages = ['179378', '179459', '179609', '179646', '180759', '285961', '285998', '286453', '321046', '321049']
nosy_count = 8.0
nosy_names = ['arigo', 'amaury.forgeotdarc', 'mark.dickinson', 'Arfrever', 'meador.inge', 'rutsky', 'Tom Krauss', 'rkmountainguy']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue16899'
versions = ['Python 3.7']

Linked PRs

Activity

  1. rutsky commented on Jan 8, 2013

    @rutsky
    rutskymannequin
    on Jan 8, 2013
    MannequinAuthor

    It would be nice if Python will be able to access variables with C99 complex types through ctypes module.

  2. rutsky
    added
    topic-ctypes
    type-featureA feature request or enhancement
    on Jan 8, 2013

  3. amauryfa commented on Jan 9, 2013

    @amauryfa
    amauryfa
    on Jan 9, 2013
    Contributor

    libffi still has no support for _Complex.

    Did you try with a pure Python solution, like the one suggested in http://objectmix.com/python/112374-re-ctypes-c99-complex-numbers.html

  4. rutsky commented on Jan 11, 2013

    @rutsky
    rutskymannequin
    on Jan 11, 2013
    MannequinAuthor

    Yes, I managed to pass and operate with matrices of complex numbers to pure C and Fortran programs by using Numpy and their ctype adapters (only for whole matrices, they don't provide c_complex type; in general see http://www.scipy.org/Cookbook/Ctypes for details).

    I suppose pure python solution that suggested in provided by you link works too:

    class Complex64(Structure):
    _fields_ = [("real", c_float), ("imag", c_float)]

    But I'm unsure is this is expected behavior or luck, and on some platform this code will not work due to different complex numbers internal representation.

    Any way this should be implemented in libffi first, and then in ctypes, so this feature request should be postponed, IMO.

  5. mdickinson commented on Jan 11, 2013

    @mdickinson
    mdickinson
    on Jan 11, 2013
    Member

    But I'm unsure is this is expected behavior or luck, and on some
    platform this code will not work due to different complex numbers
    internal representation.

    What platform? Isn't the complex number representation standard? E.g., C99 6.2.5p13 says: "Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number."

  6. mdickinson commented on Jan 27, 2013

    @mdickinson
    mdickinson
    on Jan 27, 2013
    Member

    Postponing as suggested.

  7. mdickinson
    closed this as completedon Jan 27, 2013

  8. TomKrauss commented on Jan 21, 2017

    @TomKrauss
    TomKraussmannequin
    on Jan 21, 2017
    Mannequin

    I'm trying to add support for this in cffi, which uses ctypes... apparently this is now supported in libffi (https://github.com/libffi/libffi, v3.2 Nov 2014).
    It would be nice if this issue could be re-opened, or another one created for the same purpose.

  9. mdickinson commented on Jan 22, 2017

    @mdickinson
    mdickinson
    on Jan 22, 2017
    Member

    Thanks, Tom. Re-opening.

  10. mdickinson
    reopened this on Jan 22, 2017

  11. arigo commented on Jan 29, 2017

    @arigo
    arigomannequin
    on Jan 29, 2017
    Mannequin

    • Tom: the issue is unrelated to cffi, but both ctypes and cffi could proceed to support C complexes, now that libffi support has been added.

    • Mark: the problem is that the text you quote from the C standard fixes the representation of a complex in memory, but doesn't say anything about directly passing a complex as argument or return value to a function call. Platforms use custom ways to do that. The text you quote says a complex is an array of two real numbers; but passing an array as argument to a function works by passing a pointer to the first element. Typically, this is not how complexes are passed: instead, some pointerless form of "passing two real numbers" is used.

  12. rkmountainguy commented on Jul 4, 2018

    @rkmountainguy
    rkmountainguymannequin
    on Jul 4, 2018
    Mannequin

    I concur with rutsky. Complex numbers are essential in the physical sciences, and the complex type is part of the c99 standard. Trying to shoehorn complex support by a user-defined type makes use of the builtin methods for the standard complex type clunky.

  13. rkmountainguy
    added
    3.7 (EOL)end of life
    on Jul 4, 2018

  14. arigo commented on Jul 4, 2018

    @arigo
    arigomannequin
    on Jul 4, 2018
    Mannequin

    cffi supports complex numbers since release 1.11---for direct calls using the API mode. That means that neither CFFI's ABI mode, nor ctypes, can possibly work yet. The problem is still libffi's own support, which is still not implemented (apart on a very uncommon CPU architecture, the s390).

  15. 38 remaining items

  16. skirpichev
    added a commit that references this issue on May 1, 2025

    pythongh-61103: don't use native complex types to implement F/D/G in …

    6a20faf
  17. encukou
    added a commit that references this issue on May 5, 2025

    gh-61103: don't use C _Complex types to implement F/D/G in ctypes (GH…

    8d0e07e

  18. encukou commented on May 5, 2025

    @encukou
    encukou
    on May 5, 2025
    Member

    @skirpichev said in the now-merged #133237:

    Note, that Py_FFI_SUPPORT_C_COMPLEX check configure check imply support for complex types. So, Py_HAVE_C_COMPLEX check is redundant. Though, I'm not sure if it worth removing.

    Py_HAVE_C_COMPLEX technically part of the public API namespace, so you could say PEP 387 applies to it. IMO, properly deprecating a #define-ition is too onerous to be worth it.

    I'd welcome tests that compare Python's complex numbers to the compiler's Annex G implementation (if any), so the macro might still be useful for _testcapi.

  19. skirpichev commented on May 5, 2025

    @skirpichev
    skirpichev
    on May 5, 2025
    Member

    Py_HAVE_C_COMPLEX technically part of the public API namespace

    It was introduced in 3.14, thus backward compatibility is not a problem.

    so the macro might still be useful for _testcapi.

    Lets keep it for a while.

  20. skirpichev
    closed this as completedon May 5, 2025

  21. encukou commented on May 5, 2025

    @encukou
    encukou
    on May 5, 2025
    Member

    It was introduced in 3.14

    Ah, rigth! In that case, let's remove it (some time during the beta period).
    It can be reintroduced as _Py_HAVE_C_COMPLEX.

  22. encukou
    reopened this on May 5, 2025
  23. skirpichev
    added 2 commits that reference this issue on May 5, 2025

    pythongh-61103: drop unused Py_HAVE_C_COMPLEX define

    782e2b4

    pythongh-61103: drop unused Py_HAVE_C_COMPLEX define

    92c89f8
  24. encukou
    added a commit that references this issue on May 5, 2025

    gh-61103: drop unused Py_HAVE_C_COMPLEX define (GH-133435)

    1bc1650

  25. encukou commented on May 5, 2025

    @encukou
    encukou
    on May 5, 2025
    Member

    Thank you!

  26. encukou
    closed this as completedon May 5, 2025
  27. skirpichev
    removed their assignment
    on May 7, 2025
  28. Pranjal095
    added 2 commits that reference this issue on Jul 12, 2025

    pythongh-61103: don't use C _Complex types to implement F/D/G in ctyp…

    007c71e

    pythongh-61103: drop unused Py_HAVE_C_COMPLEX define (pythonGH-133435)

    77875f6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic-ctypestype-featureA feature request or enhancement

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions