On 09Mar2021 05:00, Larry Martell <larry.mart...@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 <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
