How can I use the same imports from a different script?

Question

I have script1.py which has

from itertools import izip_longest, islice

and somewhere in script1.py , islice is used.

I have another script, script2.py , which needs to be automatically executed within script1.py because script1 's output file is script2 's input file. Problem is, script2 also needs to use the islice . Is there a way to use it without importing islice again in script2 ?

Answer 1

What you could do here is import * from script1, which would also include all its imports as well. Something like this:

# in script2.py
from script1 import *

This way you only have to do the imports once. Is this what you mean?

Answer 2

The pythonic way to use islice in script2 is to do

from itertools import islice

The import machinery in Python is pretty smart. Importing a module does not automatically load the module every time. The first step is always to check if the module is already in sys.modules . If it is (as it would be in your case), the appropriate existing reference(s) are bound to name(s) in your namespace.

Let's look at a concrete example, with the two modules below:

mod1.py

from itertools import izip_longest, islice
from mod2 import some_function

# code that uses islice and some_function

mod2.py

from itertools import islice

def some_function():
     # do the thing

If you run mod1 , the following (edited) sequence of events will happen:

1. Create an empty module object and register/cache it under sys.modules['mod1'] or sys.modules['__main__'] , depending on how you run the script.
2. Begin executing the code in mod1.py .
3. Check if itertools is in sys.modules : it's not
   1. Do some magic to find, register and load itertools into sys.modules['itertools']
   2. Add the attributes izip_longest and islice to your global namespace in the incomplete mod1
4. Check if mod2 is in sys.modules : it's not
   1. Do some magic to find mod2 and create an empty sys.modules['mod2']
   2. Begin executing the code in mod2.py .
   3. Check if itertools is in sys.modules : it is
   4. Add the attribute islice to your global namespace in the incomplete mod2 . This is basically equivalent to doing islice = sys.modules['itertools'].islice at this point. Nothing gets loaded here.
   5. Execute the def statement to create a function object, and add it to the mod2 global namespace with the name some_func .
   6. mod2 is now fully loaded
5. Execute the remaining code in mod1

So as you can see, while you can say that the itertools module is technically imported twice, it is only loaded once. The second time, the name islice is bound to a local name.

You can read the official documentation about the whole procedure here: https://docs.python.org/2/reference/simple_stmts.html#the-import-statement . This sequence of events has been around, in one implementation or another, since at least version 2.0: https://docs.python.org/2.0/ref/import.html . You may also want to read more on how modules work in general here: https://docs.python.org/2/tutorial/modules.html . As a rule, I have found the official docs to be the best teacher of Python outside maybe Stack Overflow.

The other thing to remember is that modules do not share namespaces. Globals within a module are just attributes of that particular module object. However, you could potentially do something like this:

mod2.py

from itertools import islice

def some_function(): pass

mod1.py

import mod2

#use mod2.some_function and mod2.islice as attributes of mod2

This way, you only have one explicit import of islice . I would not consider this to be a very pythonic approach though. One of the key principles of Python is "explicit is better than implicit", and readability is more important than succinctness. When you use mod2.islice , the implication to the reader is that mod2 defines a version of the function that is different from the built-in one.

As an aside, consider moving to Python 3.6+ soon. There are many improvements and new features. Python 2.x will not be supported for much longer, and many popular third party libraries such as numpy will be dropping Python 2 support entirely in coming releases.