Python: Should we always use absolute importing?

Viewed 39

I want to add a submodule for https://github.com/loonghao/photoshop-python-api, when I found all code in this repo uses absolute importing.
Well, I would follow his code style, if importing in my submodule didn't become something like this:

from photoshop.api.action_manager._main_types.action_descriptor_iterator import ActionDescriptor_Iterator

What's worse, his repo follows google guidelines, which says that everyone should make clear what a variable is for by naming it properly. That makes a line of importing easily exceeds the limit of 120 chars when using absolute importing.
What I think is that relative importing will cause error when you directly run any code in the module. But in this case no one would.
So: Is there any evidence indicating that we should always use absolute importing? Can absolute importing, which sacrefices portability and convenience, bring any convenience in maintaining when relative importing fits the situation?

1 Answers

I've found my answer: not always.

As mentioned in a comment:

You say the repo follows the Google style guide. Absolute imports are also in the Google style guide: "Do not use relative names in imports. Even if the module is in the same package, use the full package name. This helps prevent unintentionally importing a package twice."

What I think: Guidelines are written to achieve their "goal". In this case, "prevent unintentionally importing a package twice".
And the "goal" of my using relative import is to shorten the import. If I don't shorten the import, there is a bigger possibility for me to mistype the path. In my case it would take much time to find where is wrong in those large path strings.

So now my "goal" brings more convenience in maintaining than google's "goal", and it's clear that I should choose relative importing.

Related