Message278445
tl;dr PyInterpreterState does not need a "modules" field. Attached is a patch that removes it.
During interpreter startup [1] the sys module is imported using the same C API [2] as any other builtin module. That API only requires one bit of import state, sys.modules. Obviously, while the sys module is being imported, sys.modules does not exist yet. To accommodate this situation, PyInterpreterState has a "modules" field. The problem is that PyInterpreterState.modules remains significant in the C-API long after it is actually needed during startup. This creates the potential for sys.modules and PyInterpreterState.modules to be out of sync.
Currently I'm working on an encapsulation of the import state. PyInterpreterState.modules complicates the scene enough that I'd like to see it go away. The attached patch does so by adding private C-API functions that take a modules arg, rather than getting it from the interpreter state. These are used during interpreter startup, rendering PyInterpreterState.modules unnecessary and allowing sys.modules to become the single source of truth.
If this patch lands, we can close issue12633.
[1] see _Py_InitializeEx_Private() and Py_NewInterpreter() in Python/pylifecycle.c
[2] see PyModule_Create2() and _PyImport_FindBuiltin() in Python/import.c |
|
Date |
User |
Action |
Args |
2016-10-10 22:33:06 | eric.snow | set | recipients:
+ eric.snow, brett.cannon, ncoghlan |
2016-10-10 22:33:03 | eric.snow | set | messageid: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> |
2016-10-10 22:33:03 | eric.snow | link | issue28411 messages |
2016-10-10 22:33:03 | eric.snow | create | |
|