new | ask | show | jobs
zzzeek 3 days ago  [ - ]

Gonna call this an antipattern. Do you need all those modules imported in every script ? Well then you save nothing on loadup time, the time will be spent regardless. Does every script not need those imports ? Well they shouldn't be importing those things and this small set of top level imports should be curated into a better, more fine grained list (and if you want to write tools, you can certainly identify these patterns using tooling similar to that which you wrote for LazyImports).

its-summertime 2 days ago  [ - ]

    import argparse
    parser = argparse.ArgumentParser()
    parser.parse_args()
    import requests
Is an annoying bodge that a programmer should not have to think about, as a random example
sunshowers 3 days ago  [ - ]

There are often large programs where not every invocation imports every module.

The lazy import approach was pioneered in Mercurial I believe, where it cut down startup times by 3x.

mdaniel 2 days ago  [ - ]

Or, here's an idea: don't write a CLI on the hot path of a developer's flow in a scripting language. No wonder it lost out

sunshowers 2 days ago  [ - ]

I don't disagree, but I mean it was either that or C + shell back in the early 2000s, and C + shell is notorious for its non-portability across Unix and Windows—partly why Git on Windows requires an entire MSYS installation.

Today, it would be a mistake to use anything other than Rust (hence Jujutsu carrying the flame forward).

spicybright 3 days ago  [ - ]

For personal one file utility scripts, I'll sometimes only import a module on a code path that needs it. And make it global if the scope gets in the way.

It's dirty, but speeds things up vs putting all imports at the top.