STINNER Victor <vstin...@python.org> added the comment:
Myself: > Having to actually import modules to check if it's a stdlib module or not is > not convenient. Many stdlib modules have side effects on import. The "trace" usecase needs an exhaustive list of all module names. It is even less convenient to have to list all Python modules available on the system only to check modules coming from the stdlib. Ronald: > You wouldn't necessarily have to import a module to test, this is something > that could be added to importlib. One (poorly thought out) option is to add > sys._stdlib_path with the subsection of sys.path that contains the stdlib, > and a function in importlib that returns if a spec is for a stdlib module. I'm not sure how it would work. I listed different cases which have different constraints: * From a module name, check if it's part of the stdlib or not * From a module object, check if it's part of the stdlib or not For the test on the module name, how would it work with sys._stdlib_path? Should you import the module and then check if its path comes from sys._stdlib_path? Ronald: > The disadvantage of this, or for the most part anything but your initial > proposal, is that might not be save to use a function in importlib in > Py_FatalError. PR 24254 is a working implementation of my use case: only list third party extension modules on a Python fatal error. It relies on PR 24238 sys.module_names list. The implementation works when called from a signal handler (when faulthandler catch fatal signals like SIGSEGV), it avoids memory allocations on the heap (one of the limits of a signal handler). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42955> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
