-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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-101758: Clean Up Uses of Import State #101919
gh-101758: Clean Up Uses of Import State #101919
Conversation
@brettcannon, this is what I was talking about. 😄 |
|
I'm fairly sure that buildbot failure is unrelated to this PR. If the buildbot fails the next commit then I'll look into this failure further. |
OOI, did you benchmark this? Startup times are sensitive to the changes in the import system. |
This change is almost entirely moving code around and hiding import state behind internal API. We introduce no changes to behavior, nor to non-internal API. (Since there was already going to be a lot of churn, I took this as an opportunity to re-organize import.c into topically-grouped sections of code.) The motivation is to simplify a number of upcoming changes.
Specific changes:
PyInterpreterState
into a single struct field (this changes layout slightly)_PyState_AddModule()
1I avoided some related changes that would slightly change behavior, like the order of interpreter/runtime init. I may pursue those separately later.
Footnotes
I've also removed
_PyState_AddModule()
from the stable ABI manifest. It was part of "public" API since PEP 3121 was implemented 15 years ago (before a stable ABI existed) but was removed from limited API 6 years ago and then moved to internal API 4 years ago. Presumably it inadvertently slipped into the stable ABI manifest (with PEP 652) due to PC/python3dll.c. ↩