Re: importing down in code rather than at top of file.
Tobiah writes: > Is it worth while to defer the import of a large module that seldom > gets used in the script? > > > import sys > import os > > if hardly_ever_happens(): > > import large_module > large_module.do_task() I have used delayed import for different reasons: * to avoid cyclical imports * to avoid import deadlocks in multi-tasking programs (Python 2 (at least) used to protect the import machinery with a lock; which under some conditions could lead to deadlocks in a multi-tasking program). Typically, the delayed import was then in a function - relying on the fact that importing an already imported module is fast (thus, we do not lose much even if the function is called multiple times). -- https://mail.python.org/mailman/listinfo/python-list
Re: importing down in code rather than at top of file.
On 8/29/2016 1:57 PM, Tobiah wrote: Is it worth while to defer the import of a large module that seldom gets used in the script? import sys import os if hardly_ever_happens(): import large_module large_module.do_task() I imagine it takes a certain amount of processing power and memory to import a module, so it seems like I'd save those resources with the above pattern. The down side would be that it's nice to see all of the imports at the top which would follow convention. Should I care? If you delay the import, you can put it a function, such as 'almost never', and then document the delayed import with comments either mixin in with or below the real ones, such as # import large_module # in almost_never -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: importing down in code rather than at top of file.
On Tue, 30 Aug 2016 04:15:05 +1000, Chris Angelico wrote: > Don't imagine; test. Testing alone isn't really good enough. There may be perfectly valid reasons to avoid the import which won't show up in anything less than the most thorough testing imaginable. Personally I wouldn't defer an import just because it might be slow, particularly if the criterion affecting whether the import actually occurs is "probabilistic". [If it might be slow because the module is doing stuff it really shouldn't, like executing external commands during import, I'd probably just avoid the package altogether.] If the import /might/ happen as a result of normal usage, I'd want any failure to occur when the parent module is imported, not at some rather arbitrary later point. If I defer imports, it's because they're only used for features which are in some sense optional. And the documentation will state the conditions under which the import is performed (if it's for a specific method, it will be in the method's docstring). -- https://mail.python.org/mailman/listinfo/python-list
Re: importing down in code rather than at top of file.
On Mon, 29 Aug 2016 10:57:22 -0700, Tobiah wrote: > Is it worth while to defer the import of a large module that seldom > gets used in the script? > > > import sys import os > > if hardly_ever_happens(): > > import large_module large_module.do_task() > > > > I imagine it takes a certain amount of processing power and memory to > import a module, so it seems like I'd save those resources with the > above pattern. > > The down side would be that it's nice to see all of the imports at the > top which would follow convention. Should I care? > > > Tobiah That depends does it actually make a significant delay to the loading of your application (have you timed it yet) if the module does take a noticeable time to load do you want that additional delay in your rarely access conditions? IMO start-up times for an application have to be significantly long before they become an issue unless they are a shout quick utility example Libra office an take a few seconds to start but then will be running for a long time - the start-up time is not really significant. a utility to perform a bulk rename you would not want to take 30 seconds to start if it would then complete in less than 1 remember the golden riules for optimisation 1) don't 2) (for advanced programmers only) Don't yet. -- In a world without fences who needs Gates? -- https://mail.python.org/mailman/listinfo/python-list
Re: importing down in code rather than at top of file.
On Tue, Aug 30, 2016 at 3:57 AM, Tobiah wrote: > Is it worth while to defer the import of a large module that seldom > gets used in the script? > > > import sys > import os > > if hardly_ever_happens(): > > import large_module > large_module.do_task() > > > > I imagine it takes a certain amount of processing > power and memory to import a module, so it seems > like I'd save those resources with the above pattern. > > The down side would be that it's nice to see all of the > imports at the top which would follow convention. Should > I care? Don't imagine; test. Time your program with and without a top-of-file import. If the module really is large (and by "large" I mean on the scale of numpy - huge stuff), then yes, it's worth it. If you can't measure the difference, though, don't bother - just import it and have done with it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
importing down in code rather than at top of file.
Is it worth while to defer the import of a large module that seldom gets used in the script? import sys import os if hardly_ever_happens(): import large_module large_module.do_task() I imagine it takes a certain amount of processing power and memory to import a module, so it seems like I'd save those resources with the above pattern. The down side would be that it's nice to see all of the imports at the top which would follow convention. Should I care? Tobiah -- https://mail.python.org/mailman/listinfo/python-list
