GeezerVison

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').

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

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.
It's also more distracting than a regular commit. (also, you don't need to quote the whole previous message)

🤖 New build scheduled with the buildbot fleet by @vstinner for commit e9cab4a 🤖

The command will test the builders whose names match following regular expression: s390x SLES

The builders matched are:

• s390x SLES PR

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.

!buildbot AMD64 Fedora Rawhide PR

🤖 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

!buildbot AMD64 Fedora Rawhide PR

🤖 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

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

!buildbot PPC64LE CentOS9 PR

🤖 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

!buildbot PPC64LE Fedora Stable Clang PR

🤖 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

🤖 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.

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.

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.