Namespace packages in general didn't rely on pth files - only the setuptools/pkg_resources implementation of them did.

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).

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'm not really concerned about execution order issues between interdependent sitecustomize hooks, as there's already no ordering guarantee with .pth files, and if folks do need more control over the interdependencies for some reason then they can just rely on the regular import system rather than something sitecustomize specific.

So I think Chris Billington's proposed replacement is actually a reasonable idea:

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.