[isolli]

Hm, why? I'm a happy user of PYTHONPATH!

[doubleunplussed]

It's completely global, shared by all Python interpreters of all versions.

I set PYTHONPATH, but the code in that directory is solely small debugging utils of mine that I want available in every Python interpreter, and I make sure not to put anything more complex in there.

[cturner]

"It's completely global"

It doesn't have to be. You can have a launcher for a project that sets PYTHONPATH just when you launch that project.

What is bad practice is to be setting PYTHONPATH in your .bashrc, and for the reason you give - that makes it global across python launches.

[doubleunplussed]

That'll prevent it leaking to most things, but not to subprocesses of your application.

For example your application might interact with command-line tools written in Python, and unless you delete PYTHONPATH from the environment variables prior to launching any subprocesses, they'll inherit it. This could lead to subtle and confusing breakage.

[cozzyd]

So is PATH and LD_LIBRARY_PATH. You just change those as you need to...

[isolli]

Alright. I actually set it in a Docker container. It works well there.

[Uberphallus]

The only justified situation I can find is when you are working on two (or more) independent components at the same time.

My pain point in particular with PYTHONPATH (or playing with sys.path) is that people tend to use it with the only purpose of making import lines shorter, which brings naming collisions of all sorts when you aren't creative enough.

[cozzyd]

Yeah, how else do you git clone some random package and immediately use it without "installing" it?

PYTHONPATH is simple and obvious how to use, and is similar to using LD_LIBRARY_PATH and friends.