Optional imports for optional dependencies

No, not quite the same. The main difference is that when numpy is installed, it will be imported at import time — not lazily on first use. Also, there are some other considerations that make lazy unsuitable for optional dependencies as discussed in the PEP 810 thread.

If you think about it, optional imports and lazy imports are orthogonal (maybe combinable) use cases. You might not want your optional dependency to be loaded lazily. It feels like we’re trying to fit the “optional dependencies” problem into PEP 810’s goals, when it’s really addressing a different concern (I also tried).

Every suggestion on how to import optional dependencies (which I really appreciate) feels like a workaround to an issue. The variety of proposed patterns suggests that we don’t yet have a clear, standardized way to handle such a well-established concept as package extras in Python.

I fully understand the cost of introducing new syntax, and I agree we shouldn’t add syntax just to cover niche cases. I just don’t think optional dependencies are that niche — they’re already an integral part of Python’s packaging ecosystem, supported by pyproject.toml and installation tools. It feels natural that the language itself could provide a consistent mechanism to match that.

4 Likes