On 29 November 2016 at 20:54, Tomas Orsava <tors...@redhat.com> wrote: > With a metapath hook, .missing.py files are probably overkill, and the hook > can just look at one file (or a static compiled-in list) of > ModuleNotFound/ImportError messages for all missing modules, as M.-A. > Lemburg and others are suggesting. We'll just need to think about > coordinating how the list is generated/updated: the current PEP implicitly > allows other parties, besides Python and the distributors, to step in > cleanly if they need to—needing to update a single list could lead to messy > hacks.
What if, rather than using an explicitly file-based solution, this was instead defined as a new protocol module, where the new metapath hook imported a "__missing__" module and called a particular function in it (e.g. "__missing__.module_not_found(modname)")? The default missing module implementation hook would just handle CPython's optional modules, but redistributors could patch it to use a mechanism that made sense for them. For example, if we ever get to the point where the Fedora RPM database includes "Provides: pythonXYimport(module.of.interest)" data in addition to "Provides: pythonXYdist(pypi-package-name)" , the right system package to import could be reported for any module, not just standard library ones that have been split out (with the trade-off being that any such checks would make optional imports a bit slower to fail, but that could be mitigated in various ways). Specific applications could also implement their own missing module handling by providing a __missing__.py file alongside their __main__.py, and relying on directory and/or zipfile execution, or else by monkeypatching the __missing__ module at runtime. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/