[Python-ideas] PEP: Distributing a Subset of the Standard Library

[Steven D'Aprano]

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