[issue14615] pull some import state out of the interpreter state

Eric Snow added the comment: Thanks for your feedback, Martin. I'll go ahead and make a new issue for modules_reloading (and one for interp->modules when appropriate). -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue14615] pull some import state out of the interpreter state

Eric Snow added the comment: for modules_reloading, issue14618 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue14615] pull some import state out of the interpreter state

Brett Cannon added the comment: Eric put this in the bug tracker because I asked him to; I'm getting more emails about stuff about importlib that it's a little hard to keep track of everything. But originally this was about exposing what is left of the C-level APIs so it no longer was hidden

[issue14615] pull some import state out of the interpreter state

Martin v. Löwis added the comment: > Rather than being arbitrary, the motivation here is to limit amount > of the import state that is specific to CPython. What is gained by doing that? > Finally, modules (the biggie) is accessible as sys.modules. > importlib uses sys.modules. The C import im

[issue14615] pull some import state out of the interpreter state

Eric Snow added the comment: Rather than being arbitrary, the motivation here is to limit amount of the import state that is specific to CPython. I apologize that that wasn't clear. The three import-related members of PyInterpreterState (modules, modules_reloading, and modules_by_index), ar

[issue14615] pull some import state out of the interpreter state

Eric Snow added the comment: Sorry, Martin, for not looking at PEP 3121 before. I was thinking modules_by_index was a lot older. -- ___ Python tracker ___

[issue14615] pull some import state out of the interpreter state

Martin v. Löwis added the comment: > Another candidate that could probably go away, regardless of the > import work, is 'modules_by_index'. As far as I can see, there is > only one use ofinterp->modules_by_index in the cpython code-base: > PyState_FindModule() in Python/pystate.c. Likewise

[issue14615] pull some import state out of the interpreter state

Changes by Antoine Pitrou : -- nosy: +loewis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14615] pull some import state out of the interpreter state

Brett Cannon added the comment: Right, so the question is why wasn't that done in the first place? Who decided this modules_by_index concept was even worth it? -- ___ Python tracker __

[issue14615] pull some import state out of the interpreter state

Eric Snow added the comment: Curse you, undocumented API that we have to support! It could still wrap a simple get() on sys.modules, roughly like this: PyObject* PyState_FindModule(struct PyModuleDef* m) { PyObject* modules, module; modules = PyImport_GetModuleDict(); if (modules

[issue14615] pull some import state out of the interpreter state

Brett Cannon added the comment: So PyState_FindModule() is an (undocumented) part of the public API, which means that it has to somehow be supported to keep ABI compatibility (unless I am reading PEP 384 incorrectly). -- ___ Python tracker

[issue14615] pull some import state out of the interpreter state

New submission from Eric Snow : Once the dust clears from the issue 2377 and issue 13959, we should consider what import-state-related members of PyInterpreterState (Include/pystate.h) can be removed. This is in the interest of simplifying the interpreter state. The most straightforward candi