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()
The recommended convention in Python's own documentation is to import everything at the top, and on separate lines.<p>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.<p>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.
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.
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.
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.<p>Standard libraries I'm more likely to import globally, since I'm more likely to want to use them several times.<p>The most important thing is to figure out what works for you, and then be consistent about it.
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.<p>I've learned a lot by looking at the source code for guido's rietveld:
<a href="http://code.google.com/p/rietveld/source/browse/trunk/codereview/engine.py" rel="nofollow">http://code.google.com/p/rietveld/source/browse/trunk/codere...</a>
Ok I appreciate the helpful discussion, this will inform my future practice. To wrap up, I think the takeaways are:<p>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.
My preference is to use<p>from x import y<p>inside any function that needs y.<p>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.
Have a look at: <a href="http://stackoverflow.com/questions/477096/python-import-coding-style/477128#477128" rel="nofollow">http://stackoverflow.com/questions/477096/python-import-codi...</a>