PEP 810 – Explicit lazy imports

I'm a fan because it's something you can explicitly turn on and off. For my Docker based app, I really want to verify the completeness of imports. Preferably, at build and test time. In fact, most of the time I will likely disable lazy loading outright. But, I would really appreciate a faster loading CLI tool.

However, there is a pattern in python to raise an error if, say, pandas doesn't have an excel library installed, which is fine. In the future, will maintainers opt to include a bunch of unused libraries since they won't negatively impact startup time? (Think pandas including 3-4 excel parsers by default, since it will only be loaded when called). It's a much better UX, but, now if you opt out of lazy loading, your code will take longer to load than without it.

Does this fix the circular imports problem that comes up if you don't structural your programs in a hierarchical way?

YES!!!

All my code which uses import probing would fail, such as fallbacks:

  try:
    import module
  except ImportError:
    import slow_module as module

Conditional support testing would also break, like having tests which only run if module2 is available:

  try:
    import module2
  except ImportError:
    def if_has_module2(f):
      return unittest.skip("module2 not available")(f)
  else:
    def if_has_module2(f):
      return f

  @if_has_module2
  class TestModule2Bindings(....

The proto-PEP also gives an example of using

  with suppress_warnings():
    import module3

where some global configuration changes only during import.

In general, "import this" and "import antigravity" - anything with import side-effects - would stop working.

Oh, and as the proto-PEP points out, changes to sys.path and others can cause problems because of the delay between time of lazy import and time of resolution.

Then there's code where you do a long computation then make use of a package which might not be present.

  import database  # remember to install!!
  import qcd_simulation

  universe = qcd_simulation.run(seconds = 30*24*60*60)
  database.save(universe)

All of these would be replaced with "import module; module.__name__" or something to force the import, or by an explicit use to __import__.

You… can? I mean in the strictest sense you're technically not importing by file path but if you make your folder a module by slapping an __init__.py in there then your relative imports will follow the directory tree. I think as of Python 3.3 the init file is optional so it will do it by default but I can't remember if there are still some cases where it's required. The only thing you can't do is go "up" to a higher directory than the root module.

Also if that doesn't strike your fancy all of the importlib machinery is at your disposal and it's really not very much work to write an import_path() function. It's one of the patterns plug-in systems use and so is stable and expected to be used by end users. No arcane magic required.