Good or bad practice in Python: import in the middle of a file [duplicate]

Question

Suppose I have a relatively long module, but need an external module or method only once.

Is it considered OK to import that method or module in the middle of the module?

Or should imports only be in the first part of the module.

Example:

import string, pythis, pythat
...
...
...
...
def func():
     blah
     blah 
     blah
     from pysomething import foo
     foo()
     etc
     etc 
     etc
...
...
...

Please justify your answer and add links to PEPs or relevant sources

Sandry

As an example, apparently pandas does it: github.com/pandas-dev/pandas/blob/… – Cavil

Answer 1

PEP 8 authoritatively states:

Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

PEP 8 should be the basis of any "in-house" style guide, since it summarizes what the core Python team has found to be the most effective style, overall (and with individual dissent of course, as on any other language, but consensus and the BDFL agree on PEP 8).

Kaila

Alex: it is "best-practice" but not always avoidable. See the example I gave above. – Fachini

@jkp, S.Lott commented on your answer and showed why it IS avoidable in that example. The only examples I can think of would be using dynamically generated module names, thus __import__, not plain import -- in those cases you can't import until you know the name of the module you're importing, but then you're not using a plain import on it. – Kaila

The exception that I commonly indulge in is in "if name == 'main':" conditions, where the module needs to import sys or argparse in order to do i/o iff it's invoked as a script, but otherwise doesn't have any reason to import those modules. – Horgan

How is it called the moment where well-established projects contradict PEP? See "Where should this code live" at docs.djangoproject.com/en/1.8/topics/signals/… – Ambassadress

There are certainly many exceptions, since PEP8 was not given by gods. The first I can think of is to avoid circular import. Of course anyone can make anything fit any rule with some effort; my point here is whether the guidelines are there to help or to be served. – Orlon

Answer 2

There was a detailed discussion of this topic on the Python mailing list in 2001:

https://mail.python.org/pipermail/python-list/2001-July/071567.html

Here are some of the reasons discussed in that thread. From Peter Hansen, here are three reasons not to have imports all at the top of the file:

Possible reasons to import in a function:

1. Readability: if the import is needed in only one function and that's very unlikely ever to change, it might be clearer and cleaner to put it there only.

2. Startup time: if you don't have the import outside of the function definitions, it will not execute when your module is first imported by another, but only when one of the functions is called. This delays the overhead of the import (or avoids it if the functions might never be called).

3. There is always one more reason than the ones we've thought of until now.

Just van Rossum chimed in with a fourth:

4. Overhead: if the module imports a lot of modules, and there's a good chance only a few will actually be used. This is similar to the "Startup time" reason, but goes a little further. If a script using your module only uses a small subset of the functionality it can save quite some time, especially if the imports that can be avoided also import a lot of modules.

A fifth was offered as local imports are a way to avoid the problem of circular imports.

Feel free to read through that thread for the full discussion.

Loblolly

Upvoting this for providing link to a discussion, rather than just "PEP 8 says so". I would say the "meat" of it starts several messages into the thread (mail.python.org/pipermail/python-list/2001-July/097866.html). – Grobe

Links above are dead, but this one seems to work: mail.python.org/pipermail/python-list/2001-July/071567.html Some of the discussion may be deleted. – Obstruction

This is a link-only answer and is not helpful. Put the meat of your answer here instead. – Toreutics

meta.stackexchange.com/questions/8231/… - this is why link-only answers are not helpful. – Toreutics

Answer 3

Everyone else has already mentioned the PEPs, but also take care to not have import statements in the middle of critical code. At least under Python 2.6, there are several more bytecode instructions required when a function has an import statement.

>>> def f():
    from time import time
    print time()

>>> dis.dis(f)
  2           0 LOAD_CONST               1 (-1)
              3 LOAD_CONST               2 (('time',))
              6 IMPORT_NAME              0 (time)
              9 IMPORT_FROM              0 (time)
             12 STORE_FAST               0 (time)
             15 POP_TOP             

  3          16 LOAD_FAST                0 (time)
             19 CALL_FUNCTION            0
             22 PRINT_ITEM          
             23 PRINT_NEWLINE       
             24 LOAD_CONST               0 (None)
             27 RETURN_VALUE

>>> def g():
    print time()

>>> dis.dis(g)
  2           0 LOAD_GLOBAL              0 (time)
              3 CALL_FUNCTION            0
              6 PRINT_ITEM          
              7 PRINT_NEWLINE       
              8 LOAD_CONST               0 (None)
             11 RETURN_VALUE  

Sporophyll

Thanks for this, I was looking for the "what really happens internally" kind of answer. – Sika

Answer 4

If the imported module is infrequently used and the import is expensive, the in-the-middle-import is OK.

Otherwise, is it wise to follow Alex Martelli's suggestion.

Sibylle

Answer 5

It's generally considered bad practice, but sometimes it's unavoidable (say when you have to avoid a circular import).

An example of a time when it is necessary: I use Waf to build all our code. The system is split into tools, and each tool is implemented in it's own module. Each tool module can implent a detect() method to detect if the pre-requisites are present. An example of one of these may do the following:

def detect(self):
    import foobar

If this works correctly, the tool is usable. Then later in the same module the foobar module may be needed, so you would have to import it again, at function level scope. Clearly if it was imported at module level things would blow up completely.

Fachini

The import inside the def is certainly avoidable. We use try: import x; except ImportError logic blocks to keep all the imports up front. – Habitation

I particularly +1'ed the part about circular import, although I agree with everyone else's answer about PEP8. Sure, circular imports can and should be fixed, but that can be a worthless endeavor. So, in the interest of bringing value with your time, an inline import is acceptable if A) the changes required to avoid the inline import are highly risky to some live service, and|or B) fixing the circular import brings no value to the end user (including in the long run re: maintenance). Perhaps, also C) because it takes too long AND is of dubious value. – Funch

@Habitation so how do you handle the import exception? – Beeves

You say "generally considered bad practice" but can you elaborate on this? For what reasons? – Sophy

Answer 6

It is considered "Good Form" to group all imports together at the start of the file.

Modules can import other modules. It is customary but not required to place all import statements at the beginning of a module (or script, for that matter). The imported module names are placed in the importing module’s global symbol table.

From here: http://docs.python.org/tutorial/modules.html

Hawserlaid

Answer 7

95% of the time, you should put all your imports at the top of the file. One case where you might want to do a function-local import is if you have to do it in order to avoid circular imports. Say foo.py imports bar.py, and a function in bar.py needs to import something from foo.py. If you put all your imports at the top, you could have unexpected problems importing files that rely on information that hasn't been compiled yet. In this case, having a function local import can allow your code to hold off on importing the other module until its code has been fully compiled, and you call the relevant function.

However, it looks like your use-case is more about making it clear where foo() is coming from. In this case, I would far prefer one of two things:

First, rather than

from prerequisite import foo

import prerequisite directly, and later on refer to it as prerequisite.foo. The added verbosity pays itself back in spades through increased code transparency.

Alternatively, (or in conjunction with the above) if it's really such a long distance between your import and the place it's being used, it may be that your module is too big. The need for an import that nothing else uses might be an indication of a place where your code could stand to be refactored into a more manageably-sized chunk.

Glutamine

Circularity can be fixed through decomposition. Conditional imports are -- at best -- a clunky workaround. I'd say it's 99.7% of the time and the 0.3% is "until you can decompose to fix the circularity". – Habitation

Answer 8

PEP8:

Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

It is not bad practice to have scopped imports. So that the import applies only to the function you used it in.

I think the code would be more readable though if the imports where grouped together at the top of the block or if you want it globally at the top of the file.

Hallam

Answer 9

Well, I think it is a good practice to group all imports together at start of file since everyone knows where to look if want to know which libs are loaded

Ortego