Nick Coghlan added the comment: We do import modules in the Object/* code if we really need to (Grep for "PyImport_Import" in the Objects dir)
It seems to me like this case is rapidly reaching (or has even gone well past) the point where that's the sensible thing to do. A couple of key issues of concern are: - the number of modules implicitly imported at startup - the risk of attempting to import a module before the import system (and the interpreter in general) is fully initialised A simple trick for alleviating both concerns is to call PyImport_Import directly in the code path that needs it. It will be pretty quick if it gets a hit in the sys.modules cache, and most of the builtin objects aren't *used* until well after the interpreter is fully initialised (and, in the case of memoryview equality comparisons, often won't be used at all). The main alternative is to invert the dependency: move the desired functionality into a private API function and have the standard library extension module access it that way. This can end up being harder to maintain, though, and certainly isn't appropriate in this case (since "_struct.unpack_from" needs the full struct machinery to do the job). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15573> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
