Skip to content

Fix issues gh-86199 gh-86795 #92192

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

MojoVampire
Copy link
Contributor

@MojoVampire MojoVampire commented May 2, 2022

Fix issues #86199 and #86795 by centralizing copying of keyword arguments in PyObject_Call only when needed

gh-86199: `**kwargs` are not copied by the compiler when they are the only source of keyword arguments for a call. -

gh-86795: `PyObject_Call` makes copies of the keyword arguments dictionary when calling non-vectorcall functions to consistently ensure the caller's `dict` is not modified, whether the `dict` comes from the eval loop or a direct C extension call to `PyObject_Call`, matching the documented equivalence with `callable(*args, **kwargs)`. Reduces overhead of `callable(**kwargs)` ~30%.

@MojoVampire
Copy link
Contributor Author

MojoVampire commented May 2, 2022

Hmm... I've actually signed the CLA before under the old system, but it looks like the old private GitHub e-mail I was using doesn't work anymore (didn't realize this when I committed with it still configured in my .gitconfig). Not sure how to fix this retroactively. Not sure which of the several valid e-mails I now have should be the one attached to the contributor agreement for that matter.

Figured it out, managed to reset the authorship and repush so it's now credited to my new private GitHub e-mail that CLA-bot recognizes, so everything should be good now.

Preventing compiler from inserting unnecessary dict build and merge when only **kwargs passed
 Make PyObject_Call copy any incoming keyword argument dicts when the callable in question is not vectorcall to avoid possibility of callee modifying caller's dict
Add tests that verify documented equivalence between callable(**kwargs) and PyObject_Call(callable, (), kwargs)
Preventing compiler from inserting unnecessary dict build and merge when only **kwargs passed
Make PyObject_Call copy any incoming keyword argument dicts when the callable in question is not vectorcall to avoid possibility of callee modifying caller's dict
Add tests that verify documented equivalence between callable(**kwargs) and PyObject_Call(callable, (), kwargs)
@MojoVampire MojoVampire force-pushed the fix-issues-86199-86795 branch from 4a8517f to b205d6b Compare May 2, 2022 21:01
@MojoVampire MojoVampire changed the title Fix issues 86199 86795 Fix issues #86199 #86795 May 2, 2022
@MojoVampire MojoVampire changed the title Fix issues #86199 #86795 Fix issues gh-86199 gh-86795 May 2, 2022
Copy link
Contributor

@erlend-aasland erlend-aasland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, apart from one more reST nit.

Also: @mentioning people in commit messages has historically led to an awful lot of unneeded pinging from forks, other PR's, etc. I don't know if GitHub addressed this problem1, but I find it best to stay on the cautious side, and just not do that; reducing the number of pings is a welcome consideration 😉

Footnotes

  1. UPDATE: confirming that I actually got an extra ping because of the commit message

…e-86199.IZbF0m.rst

Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@protonmail.com>
@MojoVampire
Copy link
Contributor Author

Looks good, apart from one more reST nit.

Accepted as given.

Also: @mentioning people in commit messages has historically led to an awful lot of unneeded pinging from forks, other PR's, etc. I don't know if GitHub addressed this problem1, but I find it best to stay on the cautious side, and just not do that; reducing the number of pings is a welcome consideration 😉

Oops, did not know that would happen. Will avoid in the future.

…ut dict is plain dict with no history of deletions (the common case)
Copy link
Member

@methane methane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@erlend-aasland
Copy link
Contributor

Please resolve conflicts.

Also, please fix the PR title to gh-86795: <insert short summary of the actual change here>. You can describe the change in more detail (and mention gh-86199) in the PR body; this will make it easier for the core dev who merges this to create a sensible merge commit message.

@markshannon
Copy link
Member

@MojoVampire?

@erlend-aasland
Copy link
Contributor

@MojoVampire, are you planning to follow up this PR? If not, I suggest closing it.

@erlend-aasland erlend-aasland added the pending The issue will be closed if no feedback is provided label Sep 4, 2022
@MojoVampire
Copy link
Contributor Author

Sorry, I've had a hell of a year. I'm going to try to rebase this soon.

@erlend-aasland erlend-aasland removed the pending The issue will be closed if no feedback is provided label Nov 11, 2022
@python python deleted a comment Apr 7, 2025
@python-cla-bot
Copy link

The following commit authors need to sign the Contributor License Agreement:

CLA signed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants