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
Split up _testcapimodule.c #93649
Comments
Can hypothetical |
As far as I know they can, as long as |
The _testcapimodule.c file is getting too large to work with effectively. Vectorcall tests aren't the biggest issue -- it's just an area I want to work on next, so I started there. It does make it clear that MethodDescriptor2 is related to testing vectorcall, which wasn't clear before (the /* Test PEP 590 */ section had an ambiguous end). This PR lays out a general structure of how tests can be split up, with more splitting to come later if the structure is OK.
PR: #94549 |
I tried to group de 299 attributes of the _testcapi extension module. I'm not Python/getargs.c and Python/modsupport.c (parse and build arguments) (51):
datetime, pytime.c (33):
Types, metaclasses, type inheritance (wide category, not sure if it makes sense) (30):
Function calls and spawn threads to call functions (25):
Unicode, codecs (12):
Memory allocators (17):
Exceptions, "error handling", C "errno" variable and signals (13):
C types limit and size (20):
Float, PyLongObject and PyNumber C API (16):
Docstring (10):
Garbage collector (3):
Tracemalloc (3):
os module helpers (1):
Subinterpreters (1):
C API (57):
Misc (7):
|
It might be interesting to split the large _testcapi module into multiple modules. But I like the idea of starting by splitting the long C file into multiple C files. |
The `_testcapimodule.c` file is getting too large to work with effectively. This PR lays out a general structure of how tests can be split up, with more splitting to come later if the structure is OK. Vectorcall tests aren't the biggest issue -- it's just an area I want to work on next, so I'm starting here. An issue specific to vectorcall tests is that it wasn't clear that e.g. `MethodDescriptor2` is related to testing vectorcall: the `/* Test PEP 590 */` section had an ambiguous end. Separate file should make things like this much clearer. OTOH, for some pieces it might not be clear where they should be -- I left `meth_fastcall` with tests of the other calling conventions. IMO, even with the ambiguity it's still worth it to split the huge file up. I'm not sure about the buildsystem changes, hopefully CI will tell me what's wrong. @vstinner, @markshannon: Do you think this is a good idea? Automerge-Triggered-By: GH:encukou
You do not need to include |
- header files are located in $(srcdir) - dependencies must not list C files that are also in a makesetup Setup file
- header files are located in $(srcdir) - dependencies must not list C files that are also in a makesetup Setup file - generate SRCDIRS for OOT builds
Thank you for the fix! I'll |
We think that there was a problem in the buildbot hook, python/buildmaster-config#333 |
This removes the unused negative_dictoffset function: the type this function would create is available as _testcapi.HeapCTypeWithNegativeDict
How should cpython/Modules/_testcapimodule.c Lines 52 to 62 in c7e5bba
|
I'd switch to the built-in |
…H-95819) - Move PyUnicode tests to a separate file - Add some more tests for PyUnicode_FromFormat Co-authored-by: philg314 <110174000+philg314@users.noreply.github.com>
… more (pythonGH-95819) - Move PyUnicode tests to a separate file - Add some more tests for PyUnicode_FromFormat Co-authored-by: philg314 <110174000+philg314@users.noreply.github.com>
encukou commentedJun 9, 2022
Modules/_testcapimodule.c
is a nearly-8000-line behemoth with no clear structure or organization. It is getting hard to maintain.It also doesn't work well with testing (a) feature macros that affect
Python.h
and (b) module initialization, so we have additional C-API testing modules:_testmultiphase
,_testimportmultiple
,_testinternalcapi
._testbuffer
is already split out, but there are many other aspects of the API that would use a similar dedicated test suite.We should split and combine these, ideally without polluting the namespace of top-level modules.
The text was updated successfully, but these errors were encountered: