On Jan 14, 2019, at 07:17, Nick Coghlan <report@bugs.python.org> wrote:
> 
> I'll also reiterate that I am *completely* opposed to deprecating the "append entries to sys.path" usage model, as there is absolutely nothing wrong with that (if distros are ending up with an overly cluttered system that's making the standard path too long, then review the individual packages creating the clutter, don't remove the interpreter feature).

Yes, there is as Victor and others points out.  They do magical things that are difficult to debug and diagnose, and have global effects on the entire Python operating environment.

I’d be less opposed to a mechanism that is isolated to just those Python applications that need them.  I’d like to know about use cases outside of Python applications that can’t be done any other way.

> That "append to sys.path" aspect of the feature is all that's needed to make editable installs and virtual environment chaining work.
> 
> That means the aspect I'm in agreement with deprecating is the "arbitrary code execution on startup" case, but even for that, I don't think we should deprecate it until we have a comparable replacement that's more self-evidently a way of allowing arbitrary code execution, and also more obviously has the potential to make every interpreter startup in that Python installation slower.

I think we’re all in agreement about deprecating arbitrary code execution, so maybe this issue can concentrate on that, while we figure out what, if anything to do about the path extension use case.

I don’t care about slow start up of the interactive interpreter, but I do strongly care about the start up times for Python applications in general.  That’s why an opt-in mechanism is important.

> 1. In site.addsitedir, check for a __sitecustomize__ subdirectory after checking for .pth files
> 2. If any Python files are found in that directory, execute them
> 3. If "python -x importtime" has been specified, report the execution time of each of those files (this would allow both easy identification of any hooks that are being executed, as well as which ones are taking up a lot of time)
> 
> There could then be a "-Z" option that offered a more limited form of "-S": it would allow site.py itself to run, but disable the processing of `sitecustomize.py` and `__sitecustomize__` entries.

Is that a global __sitecustomize__ directory you’re talking about, or something specific to a Python application (or library?).