-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
bpo-38787: C API for module state access from extension methods (PEP 573) #19936
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
e47e21e
Include/methodobject.h: Move Py_LIMITED_API declarations to cpython/
encukou 0741598
Add ht_module to classes
d7c3551
Add PyType_GetModule and PyType_GetModuleState accessors
856f0a3
Add PyCMethod_* and machinery to call it
3053c42
Add defining_class converter to Clinic
c807aef
Add NEWS blurb
encukou 3e1aa3d
Add tests: with clinic and without clinic
a17a565
Add documentation for PEP 573
encukou f105aff
Update PEP link in NEWS entry
encukou File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Add PyCMethod_* and machinery to call it
- Loading branch information
commit 856f0a31701005b29988098de79983271ed40845
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This should use the
PyObject_TypeCheck()
macro.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.
BTW, I think we need a
PyCFunction_CheckExact()
macro now if we allow subtypes, to distinguish type checks that guard struct access (Check) from those that optimise for known behaviour (CheckExact).That probably means that we'll have to look through all usages in CPython to see which is intended. 8-]
This would generally be great to have for Cython, because then I can make Cython's own function type inherit from
PyCFunction_Type
in Py3.9+. Hmm, guess I should volunteer to do the work here…Also, the usual pattern for
PyXYZ_Check()
functions is to check for a type flag, rather than running a subtype check. Should we add one for PyCFunction, too?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.
Looks like there weren't all that many such type checks. I pushed #20024.
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.
No. Subclasses of
PyCFunction
are still quite special.The C-level check should really be used only for very specific optimizations (or the check for
print
in order to give a helpful meessage, I guess). To check for "native callables", look for vectorcall.