gh-61103: don't use native complex types in ctypes #133237
Conversation
…struct module Each complex type interpreted as an array type containing exactly two elements of the corresponding real type (real and imaginary parts, respectively).
…ctypes * drop _complex.h header * use appropriate real arrays to replace complex types
efbe0bb to
6a20faf
Compare
|
@skirpichev Thanks, it looks great. IMHO, and despite your doubts about worthiness, this should be merged. Things are simpler now, you removed lots of code, and a private header.
|
Co-authored-by: Lisandro Dalcin <dalcinl@gmail.com>
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Misc/NEWS.d/next/Library/2025-04-25-16-20-49.gh-issue-121249.uue2nK.rst
Outdated
Show resolved
Hide resolved
…ue2nK.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
|
🤖 New build scheduled with the buildbot fleet by @encukou for commit 071d57e 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133237%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
|
Ah, I missed that note, sorry! |
Done. See also minor docs correction in #133249 |
|
Failure in test_frame.py on s390x seems unrelated. |
📚 Documentation preview 📚: https://cpython-previews--133237.org.readthedocs.build/
Note, that
Py_FFI_SUPPORT_C_COMPLEXcheck configure check imply support for complex types. So,Py_HAVE_C_COMPLEXcheck is redundant. Though, I'm not sure if it worth removing.