> On 19 Jan 2021, at 12:30, STINNER Victor <report@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