I\'ve seen some Python programmers use the following style fairly consistently (we\'ll call it style 1):
import some_module
# Use some_module.some_identifier in
With the existence of the following syntax:
import some_other_module as some_module
the maintainability argument of style 2 is no longer relevant.
I tend to use style 1. Normally, I find that I explicitly reference the imported package name only a few times in a typical Python program. Everything else is methods on the object, which of course don't need to reference the imported package.
I tend to use only a few members of each module, so there's a lot of
from john import cleese
from terry import jones, gilliam
in my code. I'll import whole modules (such as os
or wx
) if I expect to be using most of the module and the module name is short. I'll also import whole modules if there is a name conflict or I want to remind the reader what that function is associated with.
import michael
import sarah
import wave
gov_speech = wave.open(sarah.palin.speechfile)
parrot_sketch = wave.open(michael.palin.justresting)
(I could use from wave import open as wave_open
, but I figure that wave.open
will be more familiar to the reader.
I personally try not to mess too much with my namespace, so in most situations I just do
import module
or import module as mod
Only real diffrence is when I have a module with a single class that's used a lot. If I had sublclassed a list
type to add some funcionality there, I'd use
from SuperImprovedListOverloadedWithFeatures import NewLIst
nl = NewList()
etc.
There are uses for both cases, so I don't think this is an either-or issue.
I'd consider using from module import x,y,z
when:
There are a fairly small number of things to import
The purpose of the functions imported is obvious when divorced from the module name. If the names are fairly generic, they may clash with others and tell you little. eg. seeing remove
tells you little, but os.remove
will probably hint that you're dealing with files.
The names don't clash. Similar to the above, but more important. Never do something like:
from os import open
import module [as renamed_module]
has the advantage that it gives a bit more context about what is being called when you use it. It has the disadvantage that this is a bit more cluttered when the module isn't really giving more information, and is slightly less performant (2 lookups instead of 1).
It also has advantages when testing however (eg. replacing os.open with a mock object, without having to change every module), and should be used when using mutable modules, e.g.
import config
config.dburl = 'sqlite:///test.db'
If in doubt, I'd always go with the import module
style.
I usually use a threshold to decide this. If I want to use a lot of things within some_module
, I'll use:
import some_module as sm
x = sm.whatever
If there's only one or two things I need:
from some_module import whatever
x = whatever
That's assuming I don't need a whatever
from some_other_module
, of course.
I tend to use the as
clause on the imports so that I can reduce my typing and substitue another module quite easily in the future.
I prefer to import X
and then use X.a
as much as possible.
My exception centers on the deeply nested modules in a big framework like Django. Their module names tend to get lengthy, and their examples all say from django.conf import settings
to save you typing django.conf.settings.DEBUG
everywhere.
If the module name is deeply nested, then the exception is to use from X.Y.Z import a
.