Eric Snow <ericsnowcurren...@gmail.com> 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), are implementation-specific. Regarding each of them:
modules_by_index was explicitly designed for C extension modules, which are (mostly) CPython-specific. It's essentially a behind-the-scenes optimization. Martin's right that we should leave it alone. modules_reloading is an artifact of the C import implementation, and (like modules_by_index) doesn't have extra bearing on the import state. However, if the importlib bootstrap renders it superfluous, why not yank it? Finally, modules (the biggie) is accessible as sys.modules. importlib uses sys.modules. The C import implementation used interp->modules directly. [1] Most (all) of that usage is going away. Again, _if_ that is the case, why keep it around? Granted, the C implementation takes advantage of interp->modules as an optimized path for getting a module (vs. the extra step of grabbing sys.modules directly), so perhaps the intention is to keep that fast path for C extension modules, etc. However, I'm naively skeptical of how much performance that buys you when all is said and done. Just to be clear, I do _not_ want to make changes willy-nilly. (I've even grown more conservative in what discussion topics I bring up.) This issue has no urgency attached to it, in my mind. It is the result of an actionable conversation that I didn't want to lose track of. If anything here is doable for 3.3, great! If not, that's fine too. If people think it's a bad idea, I'll accept that gladly, but I think consideration of the idea is justifiable. I'm glad there are plenty of sensible minds around to keep Python on a good track. :) [1] This causes a problem in a corner case (see issue 12633), but it's easy to deal with. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14615> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
