# PEP 690: Lazy Imports Again

**URL:** <https://discuss.python.org/t/pep-690-lazy-imports-again/19661>\
**Category:** PEPs\
**Created:** [October 3, 2022, 4:09pm UTC](https://discuss.python.org/t/pep-690-lazy-imports-again/19661 "2022-10-03T16:09:53Z")\
**Posts on this page:** 1\
**Showing post:** 46

<div class="post-metadata">

**Author:** ![carljm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/carljm/32/959_2.png) [@carljm](https://discuss.python.org/u/carljm)\
**Post date:** [December 5, 2022, 11:26pm UTC](https://discuss.python.org/t/pep-690-lazy-imports-again/19661/46 "2022-12-05T23:26:35Z")

</div>

> [@csm10495](#):
>
> Part of me wonders if an alternative here is to encourage imports within the function of use… I mean its sort of against the general idea of putting imports at the top, etc… though: it’s lazy… and i’ve seen it done today in some code bases with a particular module that takes a long time to import.
> 
> I’m not really saying this as a good idea, but it was rather thought-provoking to me.
> 
> Edit to add: After all: aren’t lazy imports basically syntactic-sugar around only doing the actual import once needed instead of on module import?

Yes. Per-import-statement opt-in laziness is (basically) syntactic sugar for manually inlining imports.

The main reasons to look beyond manual inlining as a solution, off the top of my head, are:

1. Manual inlining invokes the import system every time the function is called, which has a noticeable cost. The PEP 690 approach reduces this overhead to zero, after the initial reference that triggers the import.

2. Manual inlining is verbose. Sometimes syntactic sugar tastes sweet 😉

3. Manual inlining doesn’t put the name in module scope, which means e.g. it can’t be re-exported, and it can’t be used for module-level uses like type annotations (which has a lot of value when the annotations themselves are lazy via PEP 563 or 649.)

---

_[View the full topic](https://discuss.python.org/t/pep-690-lazy-imports-again/19661)._