Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.1k
gh-121249: unconditionally supportcomplex
types instruct
#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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…struct moduleEach complex type interpreted as an array type containing exactly twoelements of the corresponding real type (real and imaginary parts,respectively).
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Co-authored-by: Lisandro Dalcin <dalcinl@gmail.com>
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
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 instruct
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 aboutctypes
?
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
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.
picnixz commentedApr 25, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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. |
picnixz commentedApr 25, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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. |
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. |
picnixz left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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 themain 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. |
bedevere-bot commentedApr 30, 2025
🤖 New build scheduled with the buildbot fleet by@skirpichev for commit38fa2a7 🤖 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. |
Misc/NEWS.d/next/Library/2025-04-25-16-20-49.gh-issue-121249.uue2nK.rst OutdatedShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
f425509
intopython:mainUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
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/