0

With respect to this question: local-import-statements-in-python, quoted here at the time of my asking:

I think putting the import statement as close to the fragment that uses it helps readability by making its dependencies more clear. Will Python cache this? Should I care? Is this a bad idea?

def Process():
    import StringIO
    file_handle=StringIO.StringIO('hello world')
    #do more stuff

for i in xrange(10): Process()

A little more justification: it's for methods which use arcane bits of the library, but when I refactor the method into another file, I don't realize I missed the external dependency until I get a runtime error.

I wish to ask the following:

  • What is eventually the true difference between importing a module at the top of a .py file and importing it from inside a function definition?

For instance, I personally experienced a particular problem with the win32com.client module where my script crashed when I imported the module at the top of my file but stangely enough it seemed to execute normally after I called the import statement from within the function that was in turn calling one of its methods.

For more info on this, please see my other post here: How to launch win32 applications in separate threads in Python.

I am suspecting that this behaviour has something to do with the locals() and globals() being differently updated or not updated at all in some cases... Please enlighten me.

Community
  • 1
  • 1
stratis
  • 7,750
  • 13
  • 53
  • 94
  • Note that in a function you cannot use `*` imports. (They were allowed in old versions of python...). A part from this I don't think there is any other big difference. – Bakuriu Jan 16 '14 at 10:03

1 Answers1

0

There is no difference in how the imports are treated (with the caveat that, as the answer to that question states, the imported name is only available within the scope of the code that imported it: so if it's done inside a function, the name is local to that function).

The main difference - and the only good reason why you might want to do an import inside a function - is that anything at top level is executed when the module itself is first imported. This can lead to the possibility of circular imports: if two files both import each other at the top level, the circularity cannot be resolved and Python will raise an exception.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
  • So, could for instance some badly written module look for an attribute using the locals()[x] function and then spit out an error when it should have looked at globals()[x]? As far as I am aware, globals() shouldn't be updated if I make a local import... – stratis Jan 16 '14 at 09:55
  • Actually circular imports do *not* imply that the imports will fail. This is true only if the "main body" of *both* modules must reference something from the other module. If one of the modules uses the other module only inside function definitions (which are *not* executed during the import themselves) you are safe (which is true most of the time). Even in the bad case there are chances to fix the import error by first defining the things that are needed by the other module and then `import`ing the other module. However this design becomes complicated quite fast. – Bakuriu Jan 16 '14 at 10:00