0

Most of the topics about imports at the top of the file are about kludges to make PEP 8 happy, when someone does some slight action in the midst of imports, or about the totally different topic of relative imports. I'm curious about any runtime or other concerns of late importing a package. This topic gets close to what I'm asking, but is older and also light on specifics. I think there are some legitimate reasons to do a late import, so I'm not just asking to be pedantic.

Examples where I think a late import makes sense:

  • Running a non-standard mode like a debug mode or experimental mode and you don't want to add dependency creep or import time (e.g. using matplotlib with debugging). I find I run into this a lot, I don't want to impede development or mess up someone's environment if they check out my branch to run standard mode but I have debug pieces or even just development code to smooth out before the code is ready for a final push/merge.
  • Runtime corner cases: if a code rarely runs because it's not triggered often, but it has an import that will take up resources or import time (e.g. tensorflow) then just defer the import to when it's actually needed.
  • Deprecation: a kwarg or something triggers the older library version so you throw a warning and import the old version and its objects to stand in for the new version. Note, this might not initially be a corner case and is why I haven't included this point there.

I don't necessarily want to debate the merits of these cases, as I don't want this topic to be too broad, but rather just use these cases as examples to consider. Style and architecture aside, are there any "gotchas" to a late import, in these cases or others? Are there performance or other runtime concerns I'm not thinking about that outweigh any potential benefits (clearly, a late import on a method or class that is frequently used would not be good practice)?

Andrew Holmgren
  • 1,225
  • 1
  • 11
  • 18
  • Are you talking about lazy imports specifically? i.e. importing a module at the time when a method in the module is called. If so, there's a good article on that process in particular, which I'm actually implementing in a package. – rv.kvetch Nov 19 '21 at 00:35
  • @rv.ketch Yes, based on your description I think I am talking about "lazy imports," calling the import in a method, or class. Everyone else had been calling them "late imports," is there a difference or just different terminology? – Andrew Holmgren Nov 19 '21 at 04:35
  • Hmm, not sure. I just prefer the term "lazy imports" because it's a bit easier for me to remember what it does, i.e. it's lazy-loading the imports. But I guess they both esentially mean the same thing. – rv.kvetch Nov 19 '21 at 04:39
  • 1
    As an alternative to adding an import at the function level, I'd also take a look at a `LazyLoader` implementation which can also be used for the same purpose, as explained in [this article](https://wil.yegelwel.com/lazily-importing-python-modules/) which I think is pretty great. There are no runtime concerns that I am aware of, as this is all very lightweight. The one other benefit of using a Loader is you can raise a more helpful error when trying to lazy import a module that the user hasn't installed already. – rv.kvetch Nov 19 '21 at 04:44

0 Answers0