On Mon, Nov 28, 2016, at 15:05, Ethan Furman wrote:
Because it is unfriendly. Helpful error messages are a great tool to both beginner and seasoned programmers.
There won't be a helpful error message unless the distributor writes one.
A distribution could, for example, include an excepthook in site.py that prints an informative error message when an ImportError is unhandled for a list of modules that it knows about. [...]
As you say above, that list will fall out of date. Better to have a standard method that is easily implemented.
Whatever the standard method is, it has to be something we can direct distributors to modify, it's simply not something Python can do on its own (which means maybe distributors should be part of the conversation here). The default exception hook is as good a place as any. Maybe write most of the logic and get the distributors to just populate an empty-by-default array of structs with the module name and error message (and what about localization?) And the idea that building a ".missing.py" for every optional module that's disabled is going to adequate is a bit naive. For one thing, they're not going to *be* disabled, the distributors are going to build the whole thing and break up the installed files into packages. And you've still got to get the distributors to actually put their friendly error message in those files, and the missing.py files are build artifacts instead of a source file that they can patch.