Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged

Conversation

skirpichev
Copy link
Contributor

@skirpichevskirpichev commentedApr 24, 2025
edited by github-actionsbot
Loading

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/

…struct moduleEach complex type interpreted as an array type containing exactly twoelements of the corresponding real type (real and imaginary parts,respectively).
Co-authored-by: Lisandro Dalcin <dalcinl@gmail.com>
@skirpichev

This comment was marked as resolved.

@picnixzpicnixz self-requested a reviewApril 25, 2025 01:38
@skirpichevskirpichev added the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 25, 2025
@skirpichev

This comment was marked as resolved.

@picnixz

This comment was marked as resolved.

@picnixzpicnixz changed the titlegh-121249: make complex types available unconditionally in the struct modulegh-121249: unconditionally supportcomplex types instructApr 25, 2025
Copy link
Member

@picnixzpicnixz left a 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?

skirpichevand others added2 commitsApril 25, 2025 11:05
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
@picnixz

This comment was marked as resolved.

@picnixzpicnixz removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 25, 2025
@picnixz
Copy link
Member

picnixz commentedApr 25, 2025
edited
Loading

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

@skirpichev
Copy link
ContributorAuthor

I forgot but what was the decision about ctypes?

@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
Copy link
Member

picnixz commentedApr 25, 2025
edited
Loading

I think it's much less urgent, as for the ctypes module - support can't be available unconditionally.

Ok! I actually wondered about the fate of ctypes because I wondered whether we still needed the_complex.h header.

PS: Not sure why bots aren't started. Perhaps, this label should be added by core dev.

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.

@dalcinl
Copy link
Contributor

I forgot but what was the decision aboutctypes?

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.

@skirpichev
Copy link
ContributorAuthor

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.

@skirpichevskirpichev added the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 25, 2025
@dalcinl
Copy link
Contributor

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 thatctypes call into, but NOT the C compiler used to build CPython and ctypes.
For example, I claim that the FFI library and some third-party library that accepts/returns complex numbers can be built with a modern GCC version, thus both sides have annex G support. But then you can build CPython/ctypes with some experimental in-development compiler that does not implement annex G support just yet, and things should still work fine, ctypes is passing complex values back and forth via the FFI library, and not the C compiler used to build CPython/ctypes. If this claim is not correct, then for sure I have a misunderstanding of how the FFI library implementation works, and in such case, I apologize for all the noise.

@skirpichev
Copy link
ContributorAuthor

I don't understand what exactly you meant by "annex G support still required from system".

I tried to explain it twice:#121249 (comment) and#121249 (comment). Sorry, it's my best.

ctypes is passing complex values back and forth via the FFI library

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.

Copy link
Member

@picnixzpicnixz left a comment
edited
Loading

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

@picnixzpicnixz added 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section and removed 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelsApr 25, 2025
@picnixz

This comment was marked as outdated.

@picnixz

This comment was marked as outdated.

@picnixz
Copy link
Member

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

@skirpichev
Copy link
ContributorAuthor

CC@vstinner

@skirpichevskirpichev added 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section and removed 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelsApr 30, 2025
@bedevere-bot
Copy link

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

@bedevere-botbedevere-bot removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 30, 2025
@skirpichev
Copy link
ContributorAuthor

I see no failures, related to the pr.

@encukouencukou merged commitf425509 intopython:mainMay 2, 2025
42 checks passed
@skirpichevskirpichev deleted the struct-complex-as-array/121249 branchMay 2, 2025 16:29
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@dalcinldalcinldalcinl approved these changes

@encukouencukouencukou left review comments

@picnixzpicnixzpicnixz approved these changes

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

5 participants
@skirpichev@picnixz@dalcinl@bedevere-bot@encukou

[8]ページ先頭

©2009-2025 Movatter.jp