-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-121249: unconditionally support complex
types in struct
#132864
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
base: main
Are you sure you want to change the base?
gh-121249: unconditionally support complex
types in struct
#132864
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).
Co-authored-by: Lisandro Dalcin <dalcinl@gmail.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
complex
types in struct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot but what was the decision about ctypes
?
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
This comment was marked as resolved.
This comment was marked as resolved.
Buildbots didn't get launched apparently but that's good as we're modifying the code. Let's wait until everytihng is stable and we'll launch the buildbots again |
@picnixz, are you about this suggestion: #121249 (comment)? Patch is here: #121249 (comment). I think it's much less urgent, as for the ctypes module - support can't be available unconditionally. PS: Not sure why bots aren't started. Perhaps, this label should be added by core dev. |
Ok! I actually wondered about the fate of ctypes because I wondered whether we still needed the
I don't remember so? but maybe it is.. anyway, I'll add the label once you've confirmed whether the previous blurb needs an update. |
{'F', 1, 0, nu_complex_stub, np_complex_stub}, | ||
{'D', 1, 0, nu_complex_stub, np_complex_stub}, | ||
#endif | ||
{'F', 2*sizeof(float), _Alignof(float[2]), nu_float_complex, np_float_complex}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something we should actually care in the future but _Alignof
is deprecated since C23 and it's renamed as alignof
. It's unlikely it will be removed but for the future, we should likely use a macro Py_ALIGNOF
or something like that. It's a follow-up work though.
I may be wrong, but I still believe that ctypes support for complex can be implemented by relying exclusively on what the FFI library (and the C compiler used to build that library) supports, and not what the C compiler used to build CPython supports. When all this work settles and everything gets merged, I can try to prove my claim with a patch. |
Feel free to do this even right now. But you should be able to prove that my concern is invalid. |
The thing is, I'm still not sure what's your concern, I don't understand what exactly you meant by "annex G support still required from system". I actually agree with such claim, as long a "system" mean the C compiler used to build FFI, and the C compiler used to build a shared lib that |
I tried to explain it twice: #121249 (comment) and #121249 (comment). Sorry, it's my best.
The only way to pass it on ctypes side will be a two-element array then. I'm not sure if this will work, as it's not how complexes passed to a function. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hugovk Was it correct to amend the Misc/NEWS.d/3.14.0a1.rst for the main branch as the feature that we added there was actually changed? (that way, the online docs will contain only the most recent information and not duplicated entries). The entry will still exist in the tagged release though and will correctly reflect what 3.14.0a1 does.
EDIT: no it doesn't work that way :')
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@skirpichev I'm so sorry... but I didn't see that the entire changelog contains all previous alphas as well.. so, if we were to remove the NEWS we'll have a missing entry in the changelog page... So just restore the 3.14.0a1.rst file to what it has been but keep the new one for the beta section. You can say that previously it was conditioned though. |
CC @vstinner |
🤖 New build scheduled with the buildbot fleet by @skirpichev for commit 38fa2a7 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F132864%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
I see no failures, related to the pr. |
Each complex type interpreted as an array type containing exactly two elements of the corresponding real type (real and imaginary parts, respectively).
📚 Documentation preview 📚: https://cpython-previews--132864.org.readthedocs.build/