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

Steven D'Aprano steve at pearwood.info
Tue Nov 29 12:30:16 EST 2016


On Tue, Nov 29, 2016 at 10:55:14AM -0500, Todd wrote:
> On Tue, Nov 29, 2016 at 4:13 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> > Just as with .pth files, the possibility to hook arbitrary code
> > execution into the module search path will get abused for
> > all kinds of weird things, esp. if the whole sys.path is
> > scanned for the .missing.py module and not only the part
> > where the stdlib lives (as was suggested in the thread).
> >
> > So why not limit the PEP to just the intended use case ?

> I think a better question is why should we artificially limit the PEP?

Because YAGNI.

Overly complex, complicated systems which do more than is needed 
"because it might be useful one day" is an anti-pattern. The intended 
use-case is to allow Linux distributions to customize the error message 
on ImportError. From there, it is a small step to allow *other* people 
to do the same thing. But it is a BIG step to go from that to a solution 
that executes arbitrary code.

Before we take that big step, we ought to have a good reason.


> These is something that could be useful outside of the stdlib.

Sure. I don't think there is any proposal to prevent people outside of 
Linux package distributors from using this mechanism. I'm not sure how 
this would even be possible: if Red Hat or Debian can create a .missing 
file, so can anyone else.


> At least
> for Linux packages it is common to split out optional components of a
> python package into separate linux packages to limit the size and
> dependencies of the main package.  This could help a lot in that situation.

Well... I'm not sure how common that it. But it doesn't really matter.

This is a good argument for having a separate .missing file for each 
module, rather than a single flat registry of custom error messages. 
Separate .missing files will allow any Python package to easily install 
their own message. But either way, whether there's a single registry or 
an import hook that searches for .missing files if and only if the 
import failed, I haven't seen a strong argument for allowing arbitrary 
Python code.

(Earlier I suggested such a flat registry -- I now withdraw that 
suggestion. I'm satisfied that a separate spam.missing file containing 
the custom error message when spam.py cannot be found is a better way to 
handle this.)


-- 
Steve


More information about the Python-ideas mailing list