Repository navigation
Add support for C99 complex type (_Complex) as ctypes.c_complex #61103
Description
| 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
- gh-61103: support double complex (_Complex) type in ctypes #120894
- gh-61103: Support float and long double complex types in ctypes module #121248
- gh-61103: Add What's New entry for complex types in ctypes #129129
- gh-61103: don't use native complex types in ctypes #133237
- gh-61103: drop unused Py_HAVE_C_COMPLEX define #133435
- gh-61103: use PEP 3118 codes in the ctypes #149344
Activity
rutsky commentedon Jan 8, 2013
It would be nice if Python will be able to access variables with C99 complex types through ctypes module.
amauryfa commentedon Jan 9, 2013
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
rutsky commentedon Jan 11, 2013
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:
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.
mdickinson commentedon Jan 11, 2013
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."
mdickinson commentedon Jan 27, 2013
Postponing as suggested.
TomKrauss commentedon Jan 21, 2017
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.
mdickinson commentedon Jan 22, 2017
Thanks, Tom. Re-opening.
arigo commentedon Jan 29, 2017
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.
rkmountainguy commentedon Jul 4, 2018
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.
arigo commentedon Jul 4, 2018
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).
38 remaining items
pythongh-61103: don't use native complex types to implement F/D/G in …
gh-61103: don't use C _Complex types to implement F/D/G in ctypes (GH…
encukou commentedon May 5, 2025
@skirpichev said in the now-merged #133237:
Py_HAVE_C_COMPLEXtechnically 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.skirpichev commentedon May 5, 2025
It was introduced in 3.14, thus backward compatibility is not a problem.
Lets keep it for a while.
encukou commentedon May 5, 2025
Ah, rigth! In that case, let's remove it (some time during the beta period).
It can be reintroduced as
_Py_HAVE_C_COMPLEX.pythongh-61103: drop unused Py_HAVE_C_COMPLEX define
pythongh-61103: drop unused Py_HAVE_C_COMPLEX define
gh-61103: drop unused Py_HAVE_C_COMPLEX define (GH-133435)
encukou commentedon May 5, 2025
Thank you!
pythongh-61103: don't use C _Complex types to implement F/D/G in ctyp…
pythongh-61103: drop unused Py_HAVE_C_COMPLEX define (pythonGH-133435)