This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients brett.cannon, eric.snow, ncoghlan
Date 2016-10-10.22:33:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2016-10-10 22:33:06eric.snowsetrecipients: + eric.snow, brett.cannon, ncoghlan
2016-10-10 22:33:03eric.snowsetmessageid: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za>
2016-10-10 22:33:03eric.snowlinkissue28411 messages
2016-10-10 22:33:03eric.snowcreate