Skip to content
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

bpo-37540: vectorcall: keyword names must be strings #14682

Merged
merged 3 commits into from
Aug 16, 2019

Conversation

jdemeyer
Copy link
Contributor

@jdemeyer jdemeyer commented Jul 10, 2019

The fact that keyword names are strings is now part of the vectorcall and METH_FASTCALL protocols. The biggest concrete change is that _PyStack_UnpackDict now checks that and raises TypeError if not.

CC @markshannon @vstinner

https://bugs.python.org/issue37540

Automerge-Triggered-By: @encukou

@encukou
Copy link
Member

encukou commented Jul 13, 2019

Instead of "string", I'd say "`str` or a subclass" explicitly.
(In documentation; not necessarily in error messages)

@jdemeyer
Copy link
Contributor Author

There are many instances in the documentation (unrelated to vectorcall) where the word "string" is used. I don't see the problem here.

Concrete proposal: we leave this doc as is and I will reboot #13844 (I always planned to do that, but after all other PRs that affect documentation). In the section describing the "vectorcall protocol", I will say explicitly what "string" means for vectorcall.

@jdemeyer
Copy link
Contributor Author

Is this PR okay now or do you want me to change things?

@encukou
Copy link
Member

encukou commented Jul 19, 2019

@markshannon, you said you were looking at this PR. Is that still the case? Any progress?

@jdemeyer
Copy link
Contributor Author

jdemeyer commented Aug 4, 2019

Ping?

Copy link
Member

@encukou encukou left a comment

Choose a reason for hiding this comment

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

@markshannon seems unresponsive. I don't see an issue with this PR.

@@ -256,7 +256,7 @@
>>> f(**{1: 3}, **{1: 5})
Traceback (most recent call last):
...
TypeError: f() keywords must be strings
Copy link
Member

Choose a reason for hiding this comment

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

I see f(**{1:2}) is still tested in test_excall.py.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed. This is testing two errors at the same time (duplicate keyword and non-string keyword). Which of the two errors you get seems arbitrary to me and this PR changes the error.

@miss-islington miss-islington merged commit 0567786 into python:master Aug 16, 2019
@jdemeyer jdemeyer deleted the vectorcall_strings branch August 16, 2019 11:23
@jdemeyer
Copy link
Contributor Author

Thanks! This will help to make progress on some other PRs.

lisroach pushed a commit to lisroach/cpython that referenced this pull request Sep 10, 2019
The fact that keyword names are strings is now part of the vectorcall and `METH_FASTCALL` protocols. The biggest concrete change is that `_PyStack_UnpackDict` now checks that and raises `TypeError` if not.

CC @markshannon @vstinner 


https://bugs.python.org/issue37540
DinoV pushed a commit to DinoV/cpython that referenced this pull request Jan 14, 2020
The fact that keyword names are strings is now part of the vectorcall and `METH_FASTCALL` protocols. The biggest concrete change is that `_PyStack_UnpackDict` now checks that and raises `TypeError` if not.

CC @markshannon @vstinner 


https://bugs.python.org/issue37540
websurfer5 pushed a commit to websurfer5/cpython that referenced this pull request Jul 20, 2020
The fact that keyword names are strings is now part of the vectorcall and `METH_FASTCALL` protocols. The biggest concrete change is that `_PyStack_UnpackDict` now checks that and raises `TypeError` if not.

CC @markshannon @vstinner 


https://bugs.python.org/issue37540
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants