In Python, what happens when you import inside of a function?
Question:
What are the pros and cons of importing a Python module and/or function inside of a function, with respect to efficiency of speed and of memory?
Does it re-import every time the function is run, or perhaps just once at the beginning whether or not the function is run?
Answers:
It imports once when the function executes first time.
Pros:
- imports related to the function they’re used in
- easy to move functions around the package
Cons:
- couldn’t see what modules this module might depend on
It imports once when the function is called for the first time.
I could imagine doing it this way if I had a function in an imported module that is used very seldomly and is the only one requiring the import. Looks rather far-fetched, though…
Importing inside a function will effectively import the module once.. the first time the function is run.
It ought to import just as fast whether you import it at the top, or when the function is run. This isn’t generally a good reason to import in a def. Pros? It won’t be imported if the function isn’t called.. This is actually a reasonable reason if your module only requires the user to have a certain module installed if they use specific functions of yours…
If that’s not he reason you’re doing this, it’s almost certainly a yucky idea.
Does it re-import every time the function is run?
No; or rather, Python modules are essentially cached every time they are imported, so importing a second (or third, or fourth…) time doesn’t actually force them to go through the whole import process again. 1
Does it import once at the beginning whether or not the function is run?
No, it is only imported if and when the function is executed. 2, 3
As for the benefits: it depends, I guess. If you may only run a function very rarely and don’t need the module imported anywhere else, it may be beneficial to only import it in that function. Or if there is a name clash or other reason you don’t want the module or symbols from the module available everywhere, you may only want to import it in a specific function. (Of course, there’s always from my_module import my_function as f for those cases.)
In general practice, it’s probably not that beneficial. In fact, most Python style guides encourage programmers to place all imports at the beginning of the module file.
The very first time you import goo from anywhere (inside or outside a function), goo.py (or other importable form) is loaded and sys.modules['goo'] is set to the module object thus built. Any future import within the same run of the program (again, whether inside or outside a function) just look up sys.modules['goo'] and bind it to barename goo in the appropriate scope. The dict lookup and name binding are very fast operations.
Assuming the very first import gets totally amortized over the program’s run anyway, having the “appropriate scope” be module-level means each use of goo.this, goo.that, etc, is two dict lookups — one for goo and one for the attribute name. Having it be “function level” pays one extra local-variable setting per run of the function (even faster than the dictionary lookup part!) but saves one dict lookup (exchanging it for a local-variable lookup, blazingly fast) for each goo.this (etc) access, basically halving the time such lookups take.
We’re talking about a few nanoseconds one way or another, so it’s hardly a worthwhile optimization. The one potentially substantial advantage of having the import within a function is when that function may well not be needed at all in a given run of the program, e.g., that function deals with errors, anomalies, and rare situations in general; if that’s the case, any run that does not need the functionality will not even perform the import (and that’s a saving of microseconds, not just nanoseconds), only runs that do need the functionality will pay the (modest but measurable) price.
It’s still an optimization that’s only worthwhile in pretty extreme situations, and there are many others I would consider before trying to squeeze out microseconds in this way.
Might I suggest in general that instead of asking, “Will X improve my performance?” you use profiling to determine where your program is actually spending its time and then apply optimizations according to where you’ll get the most benefit?
And then you can use profiling to assure that your optimizations have actually benefited you, too.
What are the pros and cons of importing a Python module and/or function inside of a function, with respect to efficiency of speed and of memory?
Does it re-import every time the function is run, or perhaps just once at the beginning whether or not the function is run?
It imports once when the function executes first time.
Pros:
- imports related to the function they’re used in
- easy to move functions around the package
Cons:
- couldn’t see what modules this module might depend on
It imports once when the function is called for the first time.
I could imagine doing it this way if I had a function in an imported module that is used very seldomly and is the only one requiring the import. Looks rather far-fetched, though…
Importing inside a function will effectively import the module once.. the first time the function is run.
It ought to import just as fast whether you import it at the top, or when the function is run. This isn’t generally a good reason to import in a def. Pros? It won’t be imported if the function isn’t called.. This is actually a reasonable reason if your module only requires the user to have a certain module installed if they use specific functions of yours…
If that’s not he reason you’re doing this, it’s almost certainly a yucky idea.
Does it re-import every time the function is run?
No; or rather, Python modules are essentially cached every time they are imported, so importing a second (or third, or fourth…) time doesn’t actually force them to go through the whole import process again. 1
Does it import once at the beginning whether or not the function is run?
No, it is only imported if and when the function is executed. 2, 3
As for the benefits: it depends, I guess. If you may only run a function very rarely and don’t need the module imported anywhere else, it may be beneficial to only import it in that function. Or if there is a name clash or other reason you don’t want the module or symbols from the module available everywhere, you may only want to import it in a specific function. (Of course, there’s always from my_module import my_function as f for those cases.)
In general practice, it’s probably not that beneficial. In fact, most Python style guides encourage programmers to place all imports at the beginning of the module file.
The very first time you import goo from anywhere (inside or outside a function), goo.py (or other importable form) is loaded and sys.modules['goo'] is set to the module object thus built. Any future import within the same run of the program (again, whether inside or outside a function) just look up sys.modules['goo'] and bind it to barename goo in the appropriate scope. The dict lookup and name binding are very fast operations.
Assuming the very first import gets totally amortized over the program’s run anyway, having the “appropriate scope” be module-level means each use of goo.this, goo.that, etc, is two dict lookups — one for goo and one for the attribute name. Having it be “function level” pays one extra local-variable setting per run of the function (even faster than the dictionary lookup part!) but saves one dict lookup (exchanging it for a local-variable lookup, blazingly fast) for each goo.this (etc) access, basically halving the time such lookups take.
We’re talking about a few nanoseconds one way or another, so it’s hardly a worthwhile optimization. The one potentially substantial advantage of having the import within a function is when that function may well not be needed at all in a given run of the program, e.g., that function deals with errors, anomalies, and rare situations in general; if that’s the case, any run that does not need the functionality will not even perform the import (and that’s a saving of microseconds, not just nanoseconds), only runs that do need the functionality will pay the (modest but measurable) price.
It’s still an optimization that’s only worthwhile in pretty extreme situations, and there are many others I would consider before trying to squeeze out microseconds in this way.
Might I suggest in general that instead of asking, “Will X improve my performance?” you use profiling to determine where your program is actually spending its time and then apply optimizations according to where you’ll get the most benefit?
And then you can use profiling to assure that your optimizations have actually benefited you, too.