On Feb 26, 2019, at 12:32, Steve Dower <report@bugs.python.org> wrote:
> 
> There are 100 other ways to end up in this situation though. Why is *this* one so much worse?

Because there’s no good place to stick a pdb/breakpoint to debug such issues other than site.py, and that usually requires sudo.

> Can you offer an issue you hit that was caused by a .pth file that *wasn't* debuggable by listing sys.path?

I don’t remember the details, but yes I have been caught in this trap.  The thing is, by the time user code gets called, the damage is already done, so debugging is quite difficult.

This will be alleviated at least partially by deprecating the executing of random code.  Maybe just allowing sys.path hacking will be enough to make it not so terrible, especially if e.g. (and I haven’t check to see whether this is the case today), `python -v` shows you exactly which .pth file is extending sys.path.

The issue is discoverability.  Since pth files happen before you get an interpreter prompt, it’s too difficult to debug unexpected, wrong, or broken behavior.  My opposition would lessen if there were clear ways to debug, and preferably also prevent, pth interpretation.