Preliminary PEP 573 (module state access) implementation #3
Conversation
encukou
changed the title
Maybe reintroducing _json assertions would be a good start? See https://bugs.python.org/issue40137 |
Also adds PyType_FromModuleAndSpec constructor
|
I've rebased to make the commits show individual pieces, rather than history. |
Also adds the signatures for PyCFunction*: these were not summarized in the docs; instead and they were defined in prose with references to simpler signatures. That is hard to read.
Instead, PyCFunction_Type is made variable, so it can hold PyCMethodObject (or any future extensions) directly. (This is similar to how PyType_Type handles the need for extra storage.)
There was a problem hiding this comment.
Thanks @encukou for working on that! It's a great addition to Python 3.9 and I will ensure that it lands before beta1 :-)
As promised, here is a first review. The overall change looks good, but I didn't dig into the details yet. My main concern is about the conversion to PyObject_VAR_HEAD.
Include/cpython/methodobject.h
Outdated
| ((PyCMethodObject *)func) -> mm_class : NULL) | ||
|
|
||
| typedef struct { | ||
| PyObject_VAR_HEAD |
There was a problem hiding this comment.
Why did you convert PyCFunctionObject from PyObject_HEAD to PyObject_VAR_HEAD?
The code below suprised me:
PyCMethodObject *om = PyObject_GC_NewVar(
PyCMethodObject,
&PyCFunction_Type,
sizeof(PyCMethodObject) - sizeof(PyCFunctionObject));
There was a problem hiding this comment.
It needs space to store the new mm_class, i.e. be backed by PyCMethodObject rather than PyCFunctionObject.
What's the best way to do this?
Marcel's original work made PyCMethod a subclass of PyCFunction, which works -- but PyCFunction is not Py_TPFLAGS_BASETYPE so it can't be subclassed. It only worked because static types bypass the Py_TPFLAGS_BASETYPE check.
Maybe it would be best to add mm_class to PyCFunctionObject, i.e. to all built-in methods. But that isn't what the PEP says we'll do.
There was a problem hiding this comment.
Reverted and fixed up. PyCMethod_Type (builtin_method) now inherits from PyCFunction_Type (builtin_function_or_method), as in Marcel's branch.
…ython/ Add info about the new header file
Move the Python part of the tests to test_capi
This reverts commit 6c39835.
Properly inherit PyCMethod_Type from PyCFunction_Type
|
CPython's C code style is still foreign to me :( |
Style nitpicks
Style nitpicks
|
This is now python#19936 |
…python#91466) Fix an uninitialized bool in exception print context. `struct exception_print_context.need_close` was uninitialized. Found by oss-fuzz in a test case running under the undefined behavior sanitizer. https://oss-fuzz.com/testcase-detail/6217746058182656 ``` Python/pythonrun.c:1241:28: runtime error: load of value 253, which is not a valid value for type 'bool' #0 0xbf2203 in print_chained cpython3/Python/pythonrun.c:1241:28 #1 0xbea4bb in print_exception_cause_and_context cpython3/Python/pythonrun.c:1320:19 #2 0xbea4bb in print_exception_recursive cpython3/Python/pythonrun.c:1470:13 #3 0xbe9e39 in _PyErr_Display cpython3/Python/pythonrun.c:1517:9 ``` Pretty obvious what the ommission was upon code inspection.
WIP PEP 573 implementation. Not yet ready to send as a PR to CPython.
@dormouse759 @vstinner, do you want to comment?
Look at the diff rather than individual commits. Lots of changes have been reverted/rebased. Marcel started the implementation in 2017.
There's still lots to do:
__text_signature__.PyCMethodfromPyCFunctionetc.