On 5 December 2016 at 22:53, Tomas Orsava <torsava@redhat.com> wrote:

On 12/05/2016 01:42 PM, Nick Coghlan wrote:

Essentially, that would be the "name.missing.py" part of the draft
proposal for optional standard library modules, just with a regular
"name.py" module name and a tweak to getpath.c.

To my eye that looks like a complicated mechanism necessitating changes to
several parts of the codebase. Have you considered modifying the default
sys.excepthook implementation to read a list of modules and error messages
from a file that was generated during the build process? To me that seems
simpler, and the implementation will be only in one place.

In addition, distributors could just populate that file with their data,
thus we would have one mechanism for both use cases.

That's certainly another possibility, and one that initially appears
to confine most of the complexity to sys.excepthook(). However, the
problem you run into in that case is that CPython, by default, doesn't
have any configuration files other than site.py, sitecustomize.py,
usercustomize.py and whatever PYTHONSTARTUP points to for interactive
use. The only non-executable one that is currently defined is the
recommendation to redistributors in PEP 493 for file-based
configuration of HTTPS-verification-by-default backports to earlier
2.7.x versions.

Probably the closest analogy I can think of is the way we currently
generate _sysconfigdata-<assorted-build-qualifiers>.py in order to
capture the build time settings such that sysconfig.get_config_vars()
can report them at runtime.

So using _sysconfigdata as inspiration, it would likely be possible to
provide a "sysconfig.get_missing_modules()" API that the default
sys.excepthook() could use to report that a particular import didn't
work because an optional standard library module hadn't been built.