gh-117953: Refactor Import Machinery Code for Extension Modules #118116
Conversation
|
@encukou, content aside, do you think this change is too big, considering that it's mostly moving things around and adding a few data structures to help with that? I'd be glad to split this up if that would help, but would rather not. 😄 Don't spend much time on an answer. I'm not sure what my own answer would be yet, other than I think it's fine in priniciple. I just wanted to see if you had a quick opinion, given your experience with the code I'm changing. FWIW, I'm going to let this sit over the weekend and give myself a review on Monday. |
It's giant! :) Do you see some parts that would be an improvement on their own, which could be split out and reviewed separately? Perhaps some mechanical stuff like replacing If you don't, this patch is certainly reviewable -- over a few days. I sent a similar giant patch recently, where I couldn't figure out how to break it down further. |
|
Sounds good. I'm splitting this up into 6 different PRs. They should all be up by tomorrow. |
) This is a collection of very basic cleanups I've pulled out of gh-118116. It is mostly renaming variables and moving a couple bits of code in functionally equivalent ways.
These are cleanups I've pulled out of gh-118116. Mostly, this change moves code around to align with some future changes and to improve clarity a little. There is one very small change in behavior: we now add the module to the per-interpreter caches after updating the global state, rather than before.
This is a large change that involves refactoring the code that loads extension modules. The objective is partly to improve the clarity of the code, but mostly it's so that I can execute a subset of the constituent operations in a subsequent PR.
The changes include:
While this aligns with the sort of thing I've wanted to do for a long time, the main motivation at the moment is to drastically reduce the likelihood of problems from loading a single-phase init extension module in an isolated subinterpreter. Nearly all the changes here come from what I found I needed for a (relatively) simple solution to the isolation problem. Consequently, much of the refactoring follows the natural divisions in the flow of operations when loading an extension module.
For the sake of reducing the burden of code review for such a large change, I have purposefully avoided changing any behavior in this PR, regardless of how benign it might seem. That said, if it's still too much I'm okay with splitting this up.
For context, this is the first of 3 branches in a chain. Here are the other two, in order: