Best practices regarding PYTHONPATH

[Cameron Simpson]

On 09Mar2021 05:00, Larry Martell <larry.martell at gmail.com> wrote:
>Which is considered better? Having a long import path or setting PYTHONPATH?
>
>For example, in a project where 50% of the imports come from the same top
>level directory is it better to add that dir to the path or reference it in
>the import statements?

All the below is personal opinion.

I'd be leaving the $PYTHONPATH alone - I tweak it to access the required 
libraries, but not to change their dotted module paths.

For example, I include ~/lib/python in my personal environment to access 
my personal modules, but I don't include 
~/lib/python/cs/app/someapp/subpackage in order to shorten 
"cs.app.someapp.subpackage.foo" to just "foo".

This is largely to avoid accidental shadowing of other modules. For 
example, supposing "foo" above were the subpath "os.path". Yes, 
contrived, but that's the flavour of problem I'm avoiding.

I think I'd be ok with it provided I didn't go too far down. Eg, if all 
my "someapp"s were distinctively named I could be persuaded to use 
~/lib/python/cs/app in the $PYTHONPATH, allowing 
"someapp.subpackage.foo". But I'd still be reluctant.

If the project modules are tightly bound relative imports can get you a 
fair way. Certainly within a package I do a lot of:

    from .fixtures import these_things

to grab from the adjacent "fixtures.py" file instead of:

    from project.submodule.fixtures import these_things

And I'm usually happy to go up an additional level:

    from ..package2.fixtures import those_things

Somewhere around 3 dots I start to worry about presuming too much, but 
that is an arbitrary decision based on the discipline (or lack of it) in 
the project naming.

Cheers,
Cameron Simpson <cs at cskk.id.au>