Where to place imports

[John [H2O]]

Hello, Im writing some modules and I am a little confused about where to
place my imports...

I don't really do any class programming yet, just defining a bunch of
functions, so presently I have something along the lines of:

import sys
import os
import traceback


def Foo1(a,b):
import numpy
import datetime
return c

def Foo2(a,b):
import datetime

c = Foo1(a,b)
return c

etc...

Above obviously just for the form, but the point is, in some cases I may
import modules twice, but other times I may not use them at all, so should I
import everything into the main module? Or individually import them into
functions. Is there a performance penalty either way?

Pointers to a good reference are appreciated...

 

[Diez B. Roggisch]

Hello, Im writing some modules and I am a little confused about where to
place my imports...

I don't really do any class programming yet, just defining a bunch of
functions, so presently I have something along the lines of:

import sys
import os
import traceback


def Foo1(a,b):
import numpy
import datetime
return c

def Foo2(a,b):
import datetime

c = Foo1(a,b)
return c

etc...

Above obviously just for the form, but the point is, in some cases I may
import modules twice, but other times I may not use them at all, so should I
import everything into the main module? Or individually import them into
functions. Is there a performance penalty either way?

Usually, you should import on the top of the module. That's the cleanest
way, and the most performant one.

There is a small performance penalty when doing it inside functions -
but not too much. It boils down to a lookup if the imported module has
already been imported before.


The only valid reason for doing imports inside functions is if you
otherwise get into circular dependency hell, or have modules that need
some manipulation of the sys.path before they actually can be imported.
This is never true for system modules, and certainly to avoid if possible.

Diez

 

[John [H2O]]

So it isn't inefficient to import a bunch of modules that may not be used,
say if only one function is used that doesn't rely on a larger module like
numpy or pylab?

Thanks.

 

[Diez B. Roggisch]

So it isn't inefficient to import a bunch of modules that may not be used,
say if only one function is used that doesn't rely on a larger module like
numpy or pylab?

Well, importing can take bit of time - but that's a short latency at
startup-time, if anything.

And if your module gets imported inside a function, it *is* used, isn't it?

Diez

 

[Steve Holden]

Diez B. Roggisch wrote:
[...]

The only valid reason for doing imports inside functions is if you
otherwise get into circular dependency hell, or have modules that need
some manipulation of the sys.path before they actually can be imported.
This is never true for system modules, and certainly to avoid if possible.

Well there is also the somewhat obscure point that an import of specific
names inside a function makes them local, which *might* make a
performance difference with tight loop nesting inside - though obviously
the need for such will best be determined by benchmarking:
.... from os.path import join
.... print join
........ print join
.... 2 0 LOAD_CONST 1 (-1)
3 LOAD_CONST 2 (('join',))
6 IMPORT_NAME 0 (os.path)
9 IMPORT_FROM 1 (join)
12 STORE_FAST 0 (join)
15 POP_TOP

3 16 LOAD_FAST 0 (join)
19 PRINT_ITEM
20 PRINT_NEWLINE
21 LOAD_CONST 0 (None)
24 RETURN_VALUE 2 0 LOAD_GLOBAL 0 (join)
3 PRINT_ITEM
4 PRINT_NEWLINE
5 LOAD_CONST 0 (None)
8 RETURN_VALUE
Not a major issue, just another aspect of the question ... and of course
the OP should take the advice already given unless and until performance
becomes a problem (since it usually won't).

regards
Steve

 

[Diez B. Roggisch]

Diez B. Roggisch wrote:
[...]

The only valid reason for doing imports inside functions is if you
otherwise get into circular dependency hell, or have modules that need
some manipulation of the sys.path before they actually can be imported.
This is never true for system modules, and certainly to avoid if possible.

Well there is also the somewhat obscure point that an import of specific
names inside a function makes them local, which *might* make a
performance difference with tight loop nesting inside - though obviously
the need for such will best be determined by benchmarking:

But that could be mitigated using aliasing, which is a more general
optimization technique, as it works not only for imported names but also
for e.g. bound methods, or any other chained lookups.

Diez

 

[Steven D'Aprano]

The only valid reason for doing imports inside functions is if you
otherwise get into circular dependency hell, or have modules that need
some manipulation of the sys.path before they actually can be imported.

Or if you want to make it clear that only a single function uses the
imported module, or if you wish to avoid a potentially expensive import
until the last possible moment when you actually need it, or if you're
finicky about namespace pollution, or if you just like to put your
imports inside functions because you're weird and never use threads.

All of these are valid reasons. Whether they will give you the love and
respect of your fellow Python programmers is another question.