when to use import statements in the header, when to use import statements in the blocks where they are used?
breamoreboy at yahoo.co.uk
Wed Feb 8 03:17:59 EST 2012
On 08/02/2012 02:41, Dave Angel wrote:
> You forgot to include the list in your reply, so I'm forwarding it for
> you. One way you could have done it was to reply-all.
> On 02/07/2012 09:32 PM, Patto wrote:
>> Dave Angel：
>> On Wed, Feb 8, 2012 at 10:05 AM, Dave Angel<d at davea.name> wrote:
>>> On 02/07/2012 08:48 PM, Lei Cheng wrote:
>>>> Hi all,
>>>> In a py file, when to use import statements in the header, when to use
>>>> import statements in the blocks where they are used?
>>>> What are the best practices?
>>>> Best practice is to put all the imports at the beginning of the module,
>>> so they are easy to spot.
>>> If you put an import inside a function, it gets re-executed each time
>>> function is called, which is a waste of time. Not too much, since import
>>> first checks sys.modules to see if it's already loaded.
>>> Also, avoid the from xxx import * form, as it pollutes the
>>> namespace. And it makes it hard to figure out where a particular name is
>>> I believe these and other best practices can be found in pep8.
>> yeah, I read pep8.
>> However I find in the file path/to/djcelery/loaders.py from django-celery
>> source, there are so many import/from statements used inside functions, I
>> do not know why the author coded like this. Are there any special facts?
> I can't speak for django or django-celery. There are people that
> disagree on this, and there are some reasons to override the ones I
> mentioned. One would be large modules that are not used in most
> circumstances, or not used till the program has run for a while.
> If you put the import inside a function, you can save on startup time by
> deferring some of the logic till later. And if there's a module that
> probably won't be used at all (eg. an error handler), perhaps you can
> avoid loading it at all.
> I still think readability trumps all the other reasons, for nearly all
> programs. Only once you decide you have a performance problem should you
> change that.
There's a thread on the dev ml about imports that also discusses startup
times for anyone who's interested.
More information about the Python-list