Raise an error when importing modules compiled for an older Python #140
Conversation
befeleme
force-pushed
the
disallow-running-update-313
branch
2 times, most recently
from
7fce2e7 to
ddba252
Compare
|
|
I've tested a scratchbuild from https://koji.fedoraproject.org/koji/taskinfo?taskID=142118107 in a container and as to the on-the-fly update scenario it seems to work correctly. |
Possibly it doesn't use Py_BUILD_CORE? |
Ah, yes. It indeed doesn't. |
befeleme
force-pushed
the
disallow-running-update-313
branch
from
ddba252 to
6176ab6
Compare
|
The issue mostly comes from the usage of |
…fferent Python version This is a downstream workaround "implementing" python#137212 - the mechanism for the check exists in Python 3.15+, where it needs to be added to the standard library modules. In Fedora, we need it also in previous Python versions, as we experience segmentation fault when importing stdlib modules after update while Python is running. _curses, _tkinter, _tracemalloc and readline are not calling PyModuleDef_Init, which is modified with this patch, hence they need a direct call to the check function. Co-Authored-By: Karolina Surma <ksurma@redhat.com>
befeleme
force-pushed
the
disallow-running-update-313
branch
from
6176ab6 to
d1f8902
Compare
vstinner
left a comment
vstinner
left a comment
There was a problem hiding this comment.
LGTM.
Extensions using PyModule_Create() are modified to call _PyHack_CheckInternalAPIVersion(). Test extensions (using PyModule_Create()) are not modified, but I don't think that we should fix them.
4 participants
I was git grepping Modules with
git grep -L "PyModuleDef_Init" -- 'Modules/*.c'and compared results, finding_cursesmoduleto patch additionally in 3.13 -- the patch can't be taken "as is" from the 3.14 branch. Will appreciate another pair of eyes of the modules list.