# PEP 810: Explicit lazy imports

**URL:** <https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131>\
**Category:** PEPs\
**Created:** [October 3, 2025, 11:50am UTC](https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131 "2025-10-03T11:50:19Z")\
**Posts on this page:** 1\
**Showing post:** 465

<div class="post-metadata">

**Author:** ![ferdnyc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ferdnyc/32/6325_2.png) [@ferdnyc](https://discuss.python.org/u/ferdnyc)\
**Post date:** [November 3, 2025, 2:37pm UTC](https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131/465 "2025-11-03T14:37:03Z")

</div>

> [@kapinga](#):
>
> Put another way: library authors already have no control over when their module is imported.

> [@kapinga](#):
>
> Thus: if your module has special requirements about when it can be imported, it’s already incumbent on you to clearly document these to consuming code. The only thing that would change is to include consideration of lazy imports into that documentation.

And the chance of causing unexpected problems when attempting to enforce those requirements programmatically is high enough to make such enforcement a bad idea, IMHO. Like how calling `sys.exit(1)` when user code imports an “internal-use only module” that’s not meant to be imported directly may _seem_ like a good idea, [but it crashes `pydoc -k` scans](https://discuss.python.org/t/guidance-on-importability-of-installed-modules/25422).

---

_[View the full topic](https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131)._
