On Feb 28, 2019, at 09:40, Anthony Sottile <report@bugs.python.org> wrote:
> 
> I don't think even this is unanimous.  Things like registering codecs, instrumenting coverage in subprocesses, etc. all seem like legitimate uses of the arbitrary code execution feature

Except pth files are a terrible interface for that, given all the other problems, including weird wall-of-code inducing restrictions on what actually gets executed.

I’m in agreement with Steve Dower in principle here.  I would like to see a solution that deprecates and eventually removes arbitrary code execution in pth files, leaves sys.path extension alone (for now <wink>), and improves the discoverability and debuggability of magical pth files.

What I think Anthony is looking for are ways to register “start up functions” that get executed automatically when the Python interpreter starts up.  Perhaps somewhat analogous to atexit functions?  But if we’re going to officially support a feature like that, I think a PEP would be the right vehicle to suss out all the gory details, like, should these things be global across all invocations of the interpreter, how a user or application would disable that, how would bugs in start up functions get discovered, reported, and debugged, what if any execution order guarantees should be made, etc.