-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
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
gh-117953: Split Up _PyImport_LoadDynamicModuleWithSpec() #118203
gh-117953: Split Up _PyImport_LoadDynamicModuleWithSpec() #118203
Conversation
cd4c52d
to
378778e
Compare
378778e
to
52f0656
Compare
@encukou, if you have a few minutes, I'm mostly looking for a sanity check on this PR. |
This PR looks good, but see my comment here: #118193 (comment) An indirect test of a multiphase module with |
Thanks. I'll take a look at that. |
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.
Thanks!
+1, I think this is good to merge. The is_singlephase
thing can be sorted out later, see #117953 (comment)
I've pulled this out of #118116.
Basically, I've turned most of
_PyImport_LoadDynamicModuleWithSpec()
into two new functions (_PyImport_GetModInitFunc()
and_PyImport_RunModInitFunc()
) and moved the rest of it out into_imp_create_dynamic_impl()
. There shouldn't be any changes in behavior.This change makes some future changes simpler. This is particularly relevant to potentially calling each module init function in the main interpreter first. Thus the critical part of the PR is the addition of
_PyImport_RunModInitFunc()
, which is strictly focused on running the init func and validating the result. A later PR will take it a step farther by capturing error information rather than raising exceptions.FWIW, this change also helps readers by clarifying a bit more about what happens when an extension/builtin module is imported.