From Newsgroup: comp.lang.python

So Python 3.15 will introduce a new, “lazy” import mechanism <https://peps.python.org/pep-0810/>.

So far I have done one script where I moved an import into the
function where it was used, instead of doing it globally; this reduced
the script startup time from around 1.5 seconds down to about a
quarter second.

“Lazy” imports would avoid the need for such workarounds, while
keeping all imports together so they can be found more easily.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 26/03/2026 02.40, Lawrence D’Oliveiro wrote:

So Python 3.15 will introduce a new, “lazy” import mechanism <https://peps.python.org/pep-0810/>.

So far I have done one script where I moved an import into the
function where it was used, instead of doing it globally; this reduced
the script startup time from around 1.5 seconds down to about a
quarter second.

“Lazy” imports would avoid the need for such workarounds, while
keeping all imports together so they can be found more easily.

Interesting, I needed this as well.
Last time I checked, the suggestion
was rejected...

Good if they changed their mind.

bye,
--

piergiorgio
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/25/2026 9:40 PM, Lawrence D’Oliveiro wrote:

So Python 3.15 will introduce a new, “lazy” import mechanism <https://peps.python.org/pep-0810/>.

So far I have done one script where I moved an import into the
function where it was used, instead of doing it globally; this reduced
the script startup time from around 1.5 seconds down to about a
quarter second.

“Lazy” imports would avoid the need for such workarounds, while
keeping all imports together so they can be found more easily.

Faster startup is nice, but lazy importing doesn't reduce total runtime
of the program, right?

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 28/03/2026 05.59, DFS wrote:
[...]

Faster startup is nice, but lazy importing doesn't reduce total runtime
of the program, right?

Different objective, anyway.

It *might* reduce total runtime, it depends
on the code structure.

If the code is multi-threaded, likely having
the imports *per thread* is better than having
them globally.

YMMV

bye,
--

piergiorgio
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Thu, 26 Mar 2026 01:40:15 -0000 (UTC), Lawrence D’Oliveiro wrote:

“Lazy”

[PEP] TL;DR

From the initial idea I got that now we have to have the word lazy
scattered all over the place for every module that needs to be loaded in
such a manner:

lazy import blah
lazy import whatever
lazy from thisorthat import meh


Wouldn't it have been better if they used, e.g. "with" as a starter? Like
so:

with lazy:
import blah
import whatever
from thisorthat import meh

Then it would have been much smoother to handle.

My 2¢ worth...
--
Gilmeh

"Plaese porrf raed." -- Prof. Michael O'Longhlin, S.U.N.Y. Purchase
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Sun, 29 Mar 2026 13:49:09 GMT, Gilmeh Serda wrote:

From the initial idea I got that now we have to have the word lazy
scattered all over the place for every module that needs to be
loaded in such a manner:

lazy import blah
lazy import whatever
lazy from thisorthat import meh

Wouldn't it have been better if they used, e.g. "with" as a starter?
Like so:

with lazy:
import blah
import whatever
from thisorthat import meh

Then it would have been much smoother to handle.

I don’t think it will be needed for a great many modules. In my case,
it was only ever an issue with matplotlib.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

I don’t think it will be needed for a great many modules. In my case,
it was only ever an issue with matplotlib.

I defer importing bs4 sometimes, depending on what I'm doing.

What we really need is a way to dump out a loadable image after doing
all the imports, so you can reload your app with almost no import lag.
Lisps have supported that since our grandparents' era. Emacs still has something like it (they gave up on the classic unexec though), and
gforth has something similar too.

Maybe CRIU could be adapted for this purpose.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Sun, 29 Mar 2026 19:03:12 -0700, Paul Rubin wrote:

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

I don’t think it will be needed for a great many modules. In my
case, it was only ever an issue with matplotlib.

I defer importing bs4 sometimes, depending on what I'm doing.

That same script imports bs4, as it happens. It still manages an
overall startup time of just a quarter second.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

That same script imports bs4, as it happens. It still manages an
overall startup time of just a quarter second.

Importing bs4 can take a few hundred msec on the cheap VPS that I use it
on. So deferring it speeds the program startup by that much.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Sun, 29 Mar 2026 22:35:37 -0000 (UTC), Lawrence D’Oliveiro wrote:

I don’t think it will be needed for a great many modules.

One cannot say with certainty that this is the case. Let's revisit the
issue when things are fully implemented and we will see how people will
use it. Knowing "people" (a person can be intelligent, but people are generally morons) I don't think this is the end of the story.
--
Gilmeh

Join the Navy; sail to far-off exotic lands, meet exciting interesting
people, and kill them.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 29/03/2026 15.49, Gilmeh Serda wrote:

On Thu, 26 Mar 2026 01:40:15 -0000 (UTC), Lawrence D’Oliveiro wrote:

“Lazy”

[PEP] TL;DR

From the initial idea I got that now we have to have the word lazy
scattered all over the place for every module that needs to be loaded in
such a manner:

lazy import blah
lazy import whatever
lazy from thisorthat import meh

Wouldn't it have been better if they used, e.g. "with" as a starter? Like
so:

with lazy:
import blah
import whatever
from thisorthat import meh

Then it would have been much smoother to handle.

Why?

It's one line more and large overhead for few imports.
And the IDE can expand automatically the "lazy" part.

Furthermore, it can always be added later, as alternative
to explicit "lazy" in front of the import.

So, I personally do not see this as needed feature now.

My 2¢ worth...

Same...

bye,
--

piergiorgio
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Fri, 03 Apr 2026 11:12:38 GMT, Gilmeh Serda wrote:

On Sun, 29 Mar 2026 22:35:37 -0000 (UTC), Lawrence D’Oliveiro wrote:

I don’t think it will be needed for a great many modules.

One cannot say with certainty that this is the case.

Just based on past experience.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 28/03/2026 04:59, DFS wrote:

On 3/25/2026 9:40 PM, Lawrence D’Oliveiro wrote:

So Python 3.15 will introduce a new, “lazy” import mechanism
<https://peps.python.org/pep-0810/>.

So far I have done one script where I moved an import into the
function where it was used, instead of doing it globally; this reduced
the script startup time from around 1.5 seconds down to about a
quarter second.

“Lazy” imports would avoid the need for such workarounds, while
keeping all imports together so they can be found more easily.

Faster startup is nice, but lazy importing doesn't reduce total runtime
of the program, right?

Perhaps. Perhaps not. If the conditions for the import to run at all are
never met, total execution time can be faster. Also, there is a history of
psychology and smoke and mirrors in the world of software.
--
--
A PICKER OF UNCONSIDERED TRIFLES
--- Synchronet 3.21f-Linux NewsLink 1.2