On 02.03.2019 9:01, Barry A. Warsaw

In all the cases you've described, Python is no different from any other 
Linux software. E.g. I can install something into /etc/profile.d that 
would break the shell or set an envvar that would change the behavior of 
standard utilities.
This is by design: Linux is designed for maximum interoperability, so 
there's only one of each component in the system and everything uses it 
whenever it needs that kind of functionality. It does support multiple 
versions of the same software, but it's a compromise that significantly 
complicates maintenance (primarily how to disambiguate them when 
something requests just "component X"), so they strive to avoid it 
whenever possible.
Likewise, complete freedom for root to wreak havoc in the system is also 
by design: distro maintainers only test and support official packages; 
anything else you use is either your responsibility or an app supplier's 
if they provide official support (and are within their right to deny 
support if you tweak the environment beyond their support promise) -- 
same as for any other software as well.

This is not even specific to .pth files, either, so you won't really 
eliminate the problem by removing them. You can break any other part of 
Python in subtle ways just as well -- e.g. overwrite or override binary 
files with incompatible ones, causing segfaults in random places 
(https://stackoverflow.com/q/51816639/648265 ).

Now, Linux does have "lower tier environments" that don't automatically 
affect "higher tiers". 1) Software installed into /usr/local doesn't 
hijack system scripts thanks to absolute paths in their shebangs; 
software in /opt is not on PATH at all; 2) /etc/profile* and bashrc are 
only executed by login shells and interactive shells, not by scripts, 
limiting their effect to processes created within a user session; 3) 
anything within a user's profile or run as a regular user (including 
~/.bash*) doesn't affect system-wide settings and processes run as root.

Blindly replicating 2) won't do for Python, however. Unlike Bash which 
has all the functionality compiled in, Python has an external standard 
library and arbitrary additional packages. They both are essential for 
its operation as a system component that other software can use without 
additional manipulations, AND Python gives the user freedom on how to 
arrange them in the system. So there must be a way to provide any 
"additional manipulations" that may be needed that the built-in startup 
logic doesn't have. From administration POV, any such startup logic is a 
part of the core offer to the system: core files+libraries+connecting 
logic = Python system component, so it must be invoked whenever Python 
is invoked.
And we do already have ways to apply startup code only to a "lower-tier 
environment" if such a need arises: user-specific -- user site; 
interactive-specific -- PYTHONSTARTUP.  There's no such thing as a 
"login shell" for Python but there's Python run in a user session; 
/etc/profile* can set envvars that would apply only there.

So it seems to me that what you are asking for is "/etc/profile.d for 
Python". When designing such a feature, note, however, that the concept 
of login sessions is completely alien to Python. I believe a way to 
provide an additional site-packages directory will do (I can't readily 
see an already available way to do so in 
https://docs.python.org/3/using/cmdline.html ).