4 ms·
I didn't understand this when it first came up and I still don't. If you want to defer your imports than wait until it's needed. It might be useful if you need
by pard68 4y ago
I didn't understand this when it first came up and I still don't. If you want to defer your imports than wait until it's needed. It might be useful if you need to load a behemoth of a module for some rarely used part of a CLI tool. Otherwise, an X ms load at startup is hardly any different than the same X ms load in the middle of the execution. And on a server it's actually worse.
- mort96 4y agoEvery single CLI tool gains from this. Most Python CLI tools have terrible UX since stuff that's as simple as running it with `--help` or `--version` requires the VM to go crawling around everywhere on your disk and executing bytecode.
- pard68 4y agoI get that, but that's poor design on the tool's part, not Python's problem. Hide your imports behind functions, don't import at the global level, unless it's needed globally.
- jonnycomputer 4y agoThat's a design problem, imo, not a Python problem.
- deleted 4y ago[deleted]
- kortex 4y agoIt's hugely different. The issue occurs when you have something which does not need to execute in every context. Let's day you have a CLI which does some machine learning with several models. You don't want to execute loading every model every time you start the app. The most egregious is when you just want to display the help/usage text and not actually execute any code at all. Instead, you have to either manually lazy import (what I usually do now), or eat huge startup costs each time you screw up the command syntax.