Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34k
gh-117953: Track Extra Details in Global Extensions Cache#118532
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: Track Extra Details in Global Extensions Cache #118532
Uh oh!
There was an error while loading. Please reload this page.
Conversation
ericsnowcurrently commented May 3, 2024 • edited by bedevere-app bot
Loading Uh oh!
There was an error while loading. Please reload this page.
edited by bedevere-app bot
Uh oh!
There was an error while loading. Please reload this page.
…ongh-118532) We have only been tracking each module's PyModuleDef. However, there are some problems with that. For example, in some cases we load single-phase init extension modules from def->m_base.m_init or def->m_base.m_copy, but if multiple modules share a def then we can end up with unexpected behavior. With this change, we track the following: * PyModuleDef (same as before) * for some modules, its init function or a copy of its __dict__, but specific to that module * whether it is a builtin/core module or a "dynamic" extension * the interpreter (ID) that owns the cached __dict__ (only if cached) This also makes it easier to remember the module's kind (e.g. single-phase init) and if loading it previously failed, which I'm doing separately.
hugovk commented May 14, 2024
We're getting Does it sound like a CPython or ujson problem? |
ericsnowcurrently commented May 21, 2024
Sorry for the delay. PyCon was a bit distracting. :) I'll take a look. |
The assertion was added in gh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def. I've added a test to make sure we don't make that assumption again.
…ongh-119561) The assertion was added in pythongh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def. I've added a test to make sure we don't make that assumption again. (cherry picked from commit 0c5ebe1) Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
…119561) (gh-119632) The assertion was added in gh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def. I've added a test to make sure we don't make that assumption again. (cherry picked from commit 0c5ebe1) Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
…ongh-119561) The assertion was added in pythongh-118532 but was based on the invalid assumption that PyState_FindModule() would only be called with an already-initialized module def. I've added a test to make sure we don't make that assumption again.
We have only been tracking each module's
PyModuleDef. However, there are some problems with that. For example, in some cases we load single-phase init extension modules fromdef->m_base.m_initordef->m_base.m_copy, but if multiple modules share a def then we can end up with unexpected behavior.With this change, we track the following:
PyModuleDef(same as before)__dict__, but specific to that module__dict__(only if cached)This also makes it easier to remember the module's kind (e.g. single-phase init) and if loading it previously failed, which I'm doing in another PR.