# Async imports to reduce startup times

**URL:** <https://discuss.python.org/t/async-imports-to-reduce-startup-times/69732>\
**Category:** Ideas\
**Created:** [October 31, 2024, 12:46am UTC](https://discuss.python.org/t/async-imports-to-reduce-startup-times/69732 "2024-10-31T00:46:57Z")\
**Posts on this page:** 1\
**Showing post:** 58

<div class="post-metadata">

**Author:** ![zhangyx](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zhangyx/32/23808_2.png) [@zhangyx](https://discuss.python.org/u/zhangyx)\
**Post date:** [November 27, 2024, 4:24pm UTC](https://discuss.python.org/t/async-imports-to-reduce-startup-times/69732/58 "2024-11-27T16:24:40Z")

</div>

> [@thomas](#):
>
> I should also point out that it looks like the lazy import mechanism, the part that evaluates imports when the lazy objects are accessed, could be used to implement the “deferred expression” syntax proposed in [Backquotes for deferred expression](https://discuss.python.org/t/backquotes-for-deferred-expression/70577), at least in the global namespace. I think that’s probably a bad idea, but it’s possible.

This is true. The current version of demo implementation for deferred object can already work for lazy import. It just lacks a dedicated syntax. Here are some [related posts](https://discuss.python.org/t/backquotes-for-deferred-expression/70577/155) where I mentioned lazy imports in that thread.

Since they share the same infrastructure, I think it might be a great idea to include lazy import as one of defer expression’s core use cases and sell them together. (Please let me know how you think about it 😃)

---

_[View the full topic](https://discuss.python.org/t/async-imports-to-reduce-startup-times/69732)._
