PEP 810 – Explicit lazy imports

Re:PEP 810 – Explicit lazy imports by zahlman on Friday October 03, 2025 @05:01PM (#45467721)

With the LazyLoader technique I described at https://news.ycombinator.com/item?id=45467489 , there is no problem:

  >>> import nonexistent_module
  Traceback (most recent call last):
    File "<python-input-2>", line 1, in <module>
      import nonexistent_module
    File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
    File "<frozen importlib._bootstrap>", line 1322, in _find_and_load_unlocked
    File "<frozen importlib._bootstrap>", line 1262, in _find_spec
    File "<python-input-0>", line 8, in find_spec
      base.loader = LazyLoader(base.loader)
                               ^^^^^^^^^^^
  AttributeError: 'NoneType' object has no attribute 'loader'

The implementation should probably convert that exception back to ImportError for you, but the point is that the absence of an implementation can still be detected eagerly while the actual loading occurs lazily.

[ Parent | on HN ]

Re:PEP 810 – Explicit lazy imports by eesmith on Friday October 03, 2025 @05:29PM (#45468012)

Ahh, so you do the find first, and keep that around before loading.

I have bad memories of using a network filesystem where my Python app's startup time was 5 or more seconds because of all the small file lookups for the import were really slow.

I fixed it by importing modules in functions, only when needed, so the time went down to less than a second. (It was even better using a zipimport, but for other reasons we didn't use that option.)

If I understand things correctly, your code would have the same several-second delay as it tries to resolve everything?

[ Parent | on HN ]

Re:PEP 810 – Explicit lazy imports by zahlman on Friday October 03, 2025 @05:46PM (#45468176)

Yes, if checking for a file is slow, then checking for a file is slow. If you need to know up front whether the module exists, then you can't get around using the "figure out whether the module exists" machinery up front. And if the definition of "a module exists" includes cases where the module is represented by a file whose existence you have to check for, then there's no getting around that, either.

(Trying to do "fallback" logic with lazily-loaded modules is also susceptible to race conditions, of course. What if someone defines the module before you try to use it?)

[ Parent | on HN ]