Skip to content

Fix issues gh-86199 gh-86795 - #92192

Closed
MojoVampire wants to merge 6 commits into
python:mainfrom
MojoVampire:fix-issues-86199-86795
Closed

Fix issues gh-86199 gh-86795#92192
MojoVampire wants to merge 6 commits into
python:mainfrom
MojoVampire:fix-issues-86199-86795

Conversation

@MojoVampire

@MojoVampire MojoVampire commented May 2, 2022

Copy link
Copy Markdown
Contributor

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

MojoVampire commented May 2, 2022

Copy link
Copy Markdown
Contributor Author

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
Comment thread Objects/call.c
Comment thread Objects/call.c Outdated
Comment thread Misc/NEWS.d/next/Core and Builtins/2022-05-02-20-19-06.gh-issue-86199.IZbF0m.rst Outdated
Comment thread Objects/call.c Outdated
Comment thread Objects/call.c Outdated

@erlend-aasland erlend-aasland left a comment

Copy link
Copy Markdown
Contributor

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

Comment thread Misc/NEWS.d/next/Core and Builtins/2022-05-02-20-19-06.gh-issue-86199.IZbF0m.rst Outdated
Comment thread Objects/call.c
…e-86199.IZbF0m.rst

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

Copy link
Copy Markdown
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)

@methane methane left a comment

Copy link
Copy Markdown
Member

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
Copy Markdown
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
Copy Markdown
Member

@MojoVampire?

@erlend-aasland

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown

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

CLA signed

@github-actions

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 10, 2026
@methane

methane commented Apr 11, 2026

Copy link
Copy Markdown
Member

is this issue still exist?

@StanFromIreland

Copy link
Copy Markdown
Member

Hello! I'm sorry but I'm closing this PR as it is stale and has requested changes that have not been addressed in quite some time.

eendebakpt added a commit to eendebakpt/cpython that referenced this pull request Aug 24, 2026
Instead of a new _MAKE_KWARGS_A_DICT uop and an interpreter-side
no-alias helper, follow the structure of the original pythonGH-92192:

- The mapping-to-exact-dict conversion is folded into the existing
  _MAKE_CALLARGS_A_TUPLE op (no new uop, no macro changes).
- The callee-cannot-mutate-caller-kwargs guarantee moves into
  _PyObject_Call: the tp_call branch now receives a copy of the kwargs
  dict (empty dicts are passed as NULL), making the documented
  equivalence with callable(*args, **kwargs) hold for all C API
  callers as well (pythongh-86795).
- On free-threaded builds the interpreter simply always copies the
  kwargs dict (status quo semantics); the zero-copy optimization only
  applies to default builds for now.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting changes stale Stale PR or inactive for long period of time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants