I'm authoring a set of python coding guidelines for a team of ~30 developers. As a basis for my document, so far I've studied the Google python style guide and the PEP 8 style guide, and incorporated information from both.
One place where the Google style guide is more restrictive than PEP 8 is with imports. The Google guide requests developers only import packages and modules only, and then refer to items within by a more-qualified name. For example:
from pkg import module
...
my_class = module.MyClass()
The justification is that the "source of each identifier is indicated in a consistent way". For our project, we intend to organize with packages two or three levels deep, so to know the full source of the identifier, the reader will likely need to examine the import statement anyway. I'd like to advocate this style of import as a "preferred style":
from pkg.module import MyClass
...
my_class = MyClass()
IMHO, the readability in python constructs such as list comprehensions is improved when the names are more succinct.
What I'm unclear on is what the python interpreter might do behind the scenes. For example, is MyClass now part of the global namespace for both this module, and all importers of this module? (This would be bad, could lead to some weird bugs; if this were true, I'd advocate the Google style).
My python development experience is limited to about 6 months (and there are not many experts on our project to consult), so I wanted to get more information from the community. Here are some items I've researched already:
effbot - discussion on imports
stack overflow - import vs. from import
python documentation - modules
python documentation - import
Thank you for your responses!
In Python, there is no such thing as a variable that is global across more than one module. If you do from pkg.module import MyClass
, then MyClass
is in the global namespace of the module where you do that, but not of any other module (including modules that import the module that imports MyClass).
As for your more general question, either import mechanism can be acceptable depending on the situation. If the module name is long, you can get some shortening by importing it under a different name:
# Awkward
from package import reallylongmodule
reallylongmodule.MyClass()
# Less awkward
from package import reallylongmodule as rlm
rlm.MyClass()
Importing just the class can be okay if the class name is distinctive enough that you can tell where it comes from and what it is. However, if you have multiple modules that define classes with relatively undescriptive names (e.g., "Processor", "Unit", "Data", "Manager"), then it can be a good idea to access them via the module name to clarify what you're doing.
Style guides are ultimately guides and not laws. My own preference would be to choose a mechanism that maximizes clarity and readability. That involves a tradeoff between avoiding long and cumbersome names, and also avoiding short, vague, or cryptic names. How you make that tradeoff depends on the particular libraries you're using and how you're using them (e.g., how many modules you import, how many things you import from them).
I suggest you to use automatic code checkers, like pylint, pep8, pyflakes, instead of writing code guides.
I personally prefer to use from pkg import module
, because of possible name collisions.
from package import module
def my_fun():
module.function()
Inpreter must do 3 hash-table lookups local function namespace, current module's global namespace and imported module's namespace.
In
from package.module import function
def my_fun():
function()
it will do only 2 lookups: the last one performed in import time.