

Ask YC: Best practice for Python module imports? - skullsplitter

Im torn between two general module import styles. The import-everything-at-the-top approach where the beginning of each python file/module imports every module potentially needed later in the file OR the import-as-needed approach.<p>I know what I dont like; a file starting w/ 20+ import lines, that just seems ugly and java-y (no-flame, just sayin) to me. OTOH, the as-needed-approach seems perhaps a little too, uhm, disorganized? Although Id guess Im probably more partial to that approach.<p>This is a pretty minor stylistic issue but I havent settled on one approach and I'd like some feedback to come to some conclusion once and for all.<p>For example,<p>import foo
import baz
import bar
import quux
import django.foo 
# etc<p>vs.<p>import sys<p>def some_os_thing():
  import os
  print os.getcwd()<p>def some_http_thing():
  import urllib
  print urllib.urlopen('http://...').read()
======
makecheck
The recommended convention in Python's own documentation is to import
everything at the top, and on separate lines.

While technically Python doesn't import anything twice, it still takes nonzero
time to check the module registry (a dictionary lookup). So if this happens
every time your functions are called, it's unnecessary work, even if it's
fast.

I personally tend to do all imports in one place, with the exception of test
routines: I figure that a user of a module shouldn't really "depend" on
modules that are only needed in test mode, so e.g. I would do a local "import"
inside a _test() function.

~~~
skullsplitter
Ah ok, I wasnt aware that Python had an opinion, thats certainly (in my book
anyway) a considerable argument for that approach then!

I think I might be converging on a reasonable practice of doing all imports in
one place while including basic comments and/or just insuring at least that
imports are grouped by category / 'package'.

# Sys imports import os, sys, urllib

# django imports import django.foo ...

# google apps imports import gdata.foo ...

~~~
jerf
If you have the same 20 modules coming in over and over, consider bundling
them all up in a single module of yours that does nothing but load those 20
modules, then other modules simply import that module. There's nothing wrong
with that. Imports are as eligible for refactoring as anything else.

If you have a _different_ set of 20 modules coming in over and over, you
probably need to break up your modules more finely.

~~~
skullsplitter
Yeah Ive thought of that (lets call it the meta-import) approach as well (tho
never tried it). I dont know why I hesitated but Im glad to hear that it seems
sound.

~~~
jay_kyburz
Also note, google app engine throws a warning if try and import anywhere but
at the top.

------
timf
If you're looking at 20+ imports, it may also be an indicator that there is
too much going on in the file. With small, focused modules the question is
moot.

------
njm
My rule of thumb: I only import things locally (i.e. within a function) if it
is a conditional dependency. This is particularly true if it's something not
from the standard library. Example: I might have an application that supports
multiple database back ends, such as PostgreSQL, SQLite, etc, but I'll
conditionally import only the one applicable DB API module.

------
babyshake
My own preference is on a case-by-case basis, and typically depends on whether
I'm importing a module specific to my application, like a model or logic
library, and whether I only need it for one specific method.

Standard libraries I'm more likely to import globally, since I'm more likely
to want to use them several times.

The most important thing is to figure out what works for you, and then be
consistent about it.

------
csytan
One reason to import something within a function would be for lazy loading. If
I do end up having many different imports, I tend to group them by
library/framework.

I've learned a lot by looking at the source code for guido's rietveld:
[http://code.google.com/p/rietveld/source/browse/trunk/codere...](http://code.google.com/p/rietveld/source/browse/trunk/codereview/engine.py)

------
skullsplitter
Ok I appreciate the helpful discussion, this will inform my future practice.
To wrap up, I think the takeaways are:

a, use your head, don't let convention override reason b, In general, keep
module imports at the top of the file organized by type & package with the
caveat that a large # of imports (say more than 10 or 20) may indicate the
module is too ambitious and is a candidate for refactoring.

------
djahng
<http://www.python.org/dev/peps/pep-0008/>

There's a section on imports.

------
javert
My preference is to use

from x import y

inside any function that needs y.

OTOH I think there are good reasons to go with the official Python
recommendation, which another poster says states that all imports should be at
the top on separate lines.

------
Sal
Have a look at: [http://stackoverflow.com/questions/477096/python-import-
codi...](http://stackoverflow.com/questions/477096/python-import-coding-
style/477128#477128)

