GeezerVison

Merging this PR will not alter performance

✅ 603 untouched benchmarks
⏩ 335 skipped benchmarks¹

_{Comparing hugovk:lazy-imports (0150848) with main (3dfc89e)}

I think the

ElementTree: ModuleType | None
try:
    from defusedxml import ElementTree
except ImportError:
    ElementTree = None

import should also belong in getxmp()? It'd become a neat try: import; except: warnings.warn() early return too.

Thanks, a couple extra "icicles" knocked off.

With 3.15, on a different machine compared to yesterday:

main: 26 ms	PR before: 20 ms	PR after: 17 ms

It's certainly a bigger and unrelated change, but looks like Pillow only uses logging for a couple debug calls here and there in PIL.Image -- could be worth it to just get rid of it there (though real-world apps will generally probably import logging somehow either way, so additional laziness would need to be put in there in the stdlib...).

I made the olefile import eager again: it's an optional dependency and lazy imports affect how its related plugins get registered.

I'll have a look at logging.

Unfortunately it's not straightforward to lazy import traceback in the stdib, because if we get an exception during shutdown, the import machinery might already be shutdown: python/cpython#150073.

lazy import re in logging might be more doable, but in any case won't show up until Python 3.16.

Something like this?

--- a/src/PIL/Image.py
+++ b/src/PIL/Image.py
-import logging
...
-logger = logging.getLogger(__name__)
+class _LazyLogger:
+    """
+    Defer importing `logging` until the logger is first used to avoid slow import.
+    """
+
+    def __getattr__(self, attr: str) -> Any:
+        import logging
+
+        logger = logging.getLogger(__name__)
+        globals()["logger"] = logger
+        return getattr(logger, attr)
+
+
+logger = _LazyLogger()

Before: 16 ms	After: 12 ms

@hugovk That'd work -- but I'm also thinking... do we need the 4 logger.debug()s for importing plugin modules in PIL/Image.py at all?

@radarhere Do you think we should keep those four log lines?

I'm inclined not to.

The debug message before the import seems unnecessary, as 99% of the time, the import will succeed, and it's not part of an overall consistent use of logger.debug on our part.

As for the one on error… I'm not sure under what circumstances it would run for any of our internal plugins. From a big picture perspective though, PIL printed the exception on DEBUG and #1207 changed it to use logger. I think PIL.report (#3870) has since become the easiest way to figure out which plugins are working and which aren't.

logging dropped from Image:

Before: 20 ms	After: 10 ms

Updated: re-ran flake8-lazy src/PIL --apply set with the newer version (but evaluated f-strings), which removes some lazy imports because they're always imported, and others because they get "reified" (imported) immediately, and adds some extra imports the earlier version didn't catch.