Ronald Oussoren <ronaldousso...@mac.com> added the comment: > On 19 Jan 2021, at 12:30, STINNER Victor <rep...@bugs.python.org> wrote: > > 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?
For a module name use importlib.util.find_spec() to locate the module (or toplevel package if this is a module in package). The new importlib function could then use the spec and sys._stdlib_path to check if the spec is one for a stdlib module. This is pretty handwavy, but I do something similar in py2app (but completely based on paths calculated outside of the import machinery). For a module object you can extract the spec from the object and use the same function. > > > 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). I think we agree on that point: my counter proposal won’t work in the faulthandler scenario, and may be problematic in the Py_FatalError case as well. Ronald ---------- _______________________________________ 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
