Ask YC: Best practice for Python module imports?
9 comments
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.
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.
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 ...
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 ...
PEP 8 has an opinion on everything ;)
The best reason to do them at the top of a module, at least to me, is so you know where all the imports are. The only reason I'd ever put them in functions is to avoid circular import issues.
There's really no need to use comments; reading the module should be enough to figure out what the grouping is. My only convention is sticking all the global imports in one line at the top (PEP be damned) and grouping stuff from there.
The best reason to do them at the top of a module, at least to me, is so you know where all the imports are. The only reason I'd ever put them in functions is to avoid circular import issues.
There's really no need to use comments; reading the module should be enough to figure out what the grouping is. My only convention is sticking all the global imports in one line at the top (PEP be damned) and grouping stuff from there.
import os, sys, datetime, xmlrpclib
from django.http import Htt404, HttpResponseRedirect
from django.core import serializers
from tstumbler.util import slice_it, parse_date, flatten
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.
If you have a different set of 20 modules coming in over and over, you probably need to break up your modules more finely.
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.
If it is the same set of 20 modules, but those twenty modules are not conceptually similar, that might be something worth investigating further. That those modules need to be imported might suggest that the current module is attempting to do too many things at once.
I only point this out because a former coworker's code I've been dealing with. This was in PHP, but everything had been broken out into classes and the classes were named after the files. So, closer than just including raw PHP code into the same scope, and hopefully close enough that I don't get buried in comments to the contrary. :-)
But the coworker had the logical extreme of a module importing module. Arguably, he had the same 120 files coming in over and over. But this created all sorts of problems, the most prevalent being that a typo anywhere in these module files would bring down the entire site, since they have to be syntax checked.
So, I overall agree with jerf, with the addendum of be vigilant and be careful. :-)
If it is the same set of 20 modules, but those twenty modules are not conceptually similar, that might be something worth investigating further. That those modules need to be imported might suggest that the current module is attempting to do too many things at once.
I only point this out because a former coworker's code I've been dealing with. This was in PHP, but everything had been broken out into classes and the classes were named after the files. So, closer than just including raw PHP code into the same scope, and hopefully close enough that I don't get buried in comments to the contrary. :-)
But the coworker had the logical extreme of a module importing module. Arguably, he had the same 120 files coming in over and over. But this created all sorts of problems, the most prevalent being that a typo anywhere in these module files would bring down the entire site, since they have to be syntax checked.
So, I overall agree with jerf, with the addendum of be vigilant and be careful. :-)
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.
Also note, google app engine throws a warning if try and import anywhere but at the top.
Ah ok, I wasnt aware that Python had an opinion
See: http://www.python.org/dev/peps/pep-0008/
See: http://www.python.org/dev/peps/pep-0008/
Agreed. Unless there's a compelling reason not to (conditional imports), it's definitely best to stick with Python conventions (a la PEP8). These conventions are what keep Python one of the cleanest and most readable languages out there.
You might also want to take advantage of:
from foo import bar, baz, quux
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.
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.
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.
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...
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...
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.
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.
http://www.python.org/dev/peps/pep-0008/
There's a section on imports.
There's a section on imports.
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.
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.
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.
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.
For example,
import foo import baz import bar import quux import django.foo # etc
vs.
import sys
def some_os_thing(): import os print os.getcwd()
def some_http_thing(): import urllib print urllib.urlopen('http://...').read()