Repo Added
|
Files
914
|
Badge
Embed ▾
README BADGES
|
push
github
Avoid exporting incorrect `PyInit_*` symbols (#12889) (#12893) Using the `#[pymodule]` derive macro in PyO3 0.21 always causes a `PyInit_*` symbol with a matching name to be exported in the output `cdylib`. This is required for the top-level module, in order for Python to import it---it needs to know which symbol in a shared library file it should call---but submodules must be manually initialised, so do not need it. Including it is typically harmless (and something we've been doing for a long time), but it is technically against the coding rules for CPython extensions[^1]. Recent versions of `abi3audit` (0.0.11+) have tightened their symbol checkers to better match the CPython guidelines, which causes our wheels to be rejected by their audits. This is, in theory, not a break of abi3 because CPython could never introduce an API-elvel `PyInit_*` function themselves without causing problems, so there ought to be no problems for our users, even with future Python versions. That said, we still want to pass the audit, because the coding guidelines are useful. This commit is not the cleanest way of doing things. PyO3 0.22 includes a `#[pymodule(submodule)]` option on the attribute macro, which lets us use all the standard code generation while suppressing the unnecessary `PyInit_*` symbol. When we are ready to move to PyO3 0.22, we probably want to revert this commit to switch to that form. [^1]: https://docs.python.org/3/c-api/intro.html (cherry picked from commit 120b73d21) Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
40 of 40 new or added lines in 3 files covered. (100.0%)
25 existing lines in 3 files now uncovered.66722 of 74191 relevant lines covered (89.93%)
232269.04 hits per line
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|