On Mon, Nov 28, 2016 at 12:05:01PM -0800, Ethan Furman wrote:
Honestly, though, I'm not sure of the need for the PEP in general. "However, there is as of yet no standardized way of dealing with importing a missing standard library module." is simply not true. The standardized way of dealing with it is that the import statement will raise an ImportError exception. Why exactly is that not good enough?
Because it is unfriendly. Helpful error messages are a great tool to both beginner and seasoned programmers.
Random already covers that. There's no reason why packagers can't fix that.
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.
I think you have misunderstood Random's observation. Random notes correctly that treating "curses on Windows" as a special case will get out of date. Today its curses, tomorrow it might be curses and foo, then curses foo and bar, then just foo. Who knows? And what about Linux and Mac users? Might we start deploying third-party replacements for Windows-only std lib modules? (If any.) This is effectively a black-list: - don't add a .missing file for these modules where the list depends on guessing what *other* people do. But Random's observation doesn't apply to the packager. They cannot fall out of date, since they're generating a *white-list* of modules they have split out of the std lib into a separate package. Instead of the packager doing this: - remove foo, bar, baz from the standard python package; - add foo.missing, bar.missing, baz.missing to the python package; - add foo, bar, baz to the python-extras package Random suggest that they do this: - remove foo, bar, baz from the standard python package; - add foo, bar, baz to the list of modules that ImportError knows about; - add foo, bar, baz to the python-extras package. It can no more get out of date than can the .missing files. Instead of adding a complex mechanism for searching the PYTHONPATH twice, the second time looking for .missing files, here's a counter proposal: - Add a single config file in a known, standard place, call it "missing.ini" for the sake of the argument; - If present, that file should be a list of module names as keys and custom error messages as values; foo: try running "yum install spam-python" bar: try running "yum install spam-python" baz: try running "yum install eggs-python" - When ImportError is raised, Python looks at that file, and if the module name is found, it gives the custom error message in addition to the regular error message: import foo ImportError: No module named 'foo' try running "yum install spam-python" -- Steve