In the long run I think you'll appreciate having most of your imports at the top of the file, that way you can tell at a glance how complicated your module is by what it needs to import.
If I'm adding new code to an existing file I'll usually do the import where it's needed and then if the code stays I'll make things more permanent by moving the import line to the top of the file.
One other point, I prefer to get an ImportError
exception before any code is run — as a sanity check, so that's another reason to import at the top.
You can use a linter to check for unused modules.
Well, it is not that simple.
Actually, import statement in many aspects looks like direct definition of something in place of it. If you write
class test:
from platform import system
it looks exactly like
class test:
def system():
# ....
and then you have following problems:
- you can't use just system() because system is not in global scope
- you can't use self.system() because in this form, python automatically passes
self
as first argument, but system() has no parameters and you'll get TypeError: system() takes no arguments (1 given)
- you can't use test.system() because system() looks like a plain method, and you'll get
TypeError: unbound method system() must be called with test instance as first argument (got nothing instead)
There are several ways around these problems:
- place
import platform
at top level, and use platform.system() wherever you want, thus fixing issue #1 from prev. list
- use
staticmethod
decorator, fixing issues #2 and #3 from prev. list.
like
class test:
from platform import system
system = staticmethod(system)
then you can use either self.system() or test.system()
Actually, you should just import everything in toplevel and forget about it.
You only have to split import declarations if you need something special for running.
Like
import foo
import bar
def fun(param1, param2):
# .....
if __name__ == '__main__':
from sys import argv
if len(argv) > 2:
fun(argv[1], argv[2])
In this example, moving from sys import argv
is valid, because it is needed only when running a script. But when you use it as an imported module, there is no need in this import.
But that is not your case, because in your case, system() is always needed for test class, so there is no reason to move this import from toplevel. Just leave it there and never mind.
Best Answer
It's the most common style to put every import at the top of the file. PEP 8 recommends it, which is a good reason to do it to start with. But that's not a whim, it has advantages (although not critical enough to make everything else a crime). It allows finding all imports at a glance, as opposed to looking through the whole file. It also ensures everything is imported before any other code (which may depend on some imports) is executed.
NameError
s are usually easy to resolve, but they can be annoying.There's no (significant) namespace pollution to be avoided by keeping the module in a smaller scope, since all you add is the actual module (no,
import *
doesn't count and probably shouldn't be used anyway). Inside functions, you'd import again on every call (not really harmful since everything is imported once, but uncalled for).