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.
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'.
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
Edit: it is also non-trivial from a performance point of view to have a module import every time a function is called...
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 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. :-)
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.
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.
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.
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 ...
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.
Edit: it is also non-trivial from a performance point of view to have a module import every time a function is called...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 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. :-)
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/
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:
if you aren't already.