Prompt and scope
A command-line tool contains large dependencies used by only some subcommands. The team wants Python 3.15 lazy import to reduce startup time and resident memory, while still supporting Python 3.14. Some modules register plugins, read environment variables, or validate configuration during import. Design the migration, tests, and fallback.
PEP 810 is explicit and opt-in. Python 3.15 documentation is still pre-release, so a beta behavior is not universal stable support.
What the interviewer evaluates
The interviewer expects you to know that lazy imports move errors and side effects to first use, and to distinguish module-level lazy statements, the __lazy_modules__ compatibility mechanism, and global modes.
A strong answer covers circular imports, type checking, plugin registration, thread races, observability, and a kill switch rather than only claiming faster startup.
Clarifications to ask first
- Is the cost module lookup, top-level execution, or application initialization?
- Which modules depend on import-time side effects or must fail early?
- What is the minimum Python version and release channel?
- Must
--help, completion, and plugin discovery remain unchanged? - How will you separate first-use latency from cold-start gains?
A 30-second answer
“I would profile with -X importtime, then mark only optional, side-effect-safe modules as explicitly lazy. Critical configuration and plugin registration remain eager because errors move to first use. Python 3.14 gets a __lazy_modules__ compatibility declaration and remains eager. I would measure cold start, first-use latency, concurrent first access, and error logs, keeping sys.set_lazy_imports('none') or a configuration switch for rollback.”
Step-by-step solution
Establish an import-cost baseline
Use -X importtime and startup spans to separate lookup, compilation, top-level execution, and application initialization. A large module is not automatically a good lazy candidate; if every first command needs it, laziness merely moves work onto the interaction path.
Choose an explicit syntax boundary
PEP 810 permits module-level lazy import json and lazy from json import dumps. The syntax is not allowed inside functions, classes, try, or star imports; normal imports remain eager. Keep declarations in optional feature modules so dependency timing is visible.
lazy import expensive_report
lazy from plugins.pdf import render
def run_report(data):
return expensive_report.build(data)Manage first use and error timing
Accessing a lazy name loads the module and reifies the object. ImportError, top-level configuration errors, and side-effect failures therefore move from the import statement to the use site. A CLI should prewarm before running a subcommand and map failures to stable messages instead of letting them surface on arbitrary request threads.
Handle side effects, cycles, and types
Plugin registration, logging handlers, environment reads, and database-driver setup normally stay eager or move behind an explicit initialize(). Lazy timing can expose circular imports; enforce a simple dependency direction and startup contract tests. TYPE_CHECKING can preserve static imports, but runtime first-use paths still need tests.
Support older versions
Python 3.14 does not parse lazy syntax. PEP 810 provides __lazy_modules__, a list of module names that Python 3.15 may treat as lazy while older versions ignore it and import eagerly. Run syntax, import, and CLI tests for every supported interpreter, not only 3.15 beta.
Control global-mode risk
PEP 810 also defines normal, all, and none modes and a filter. An application can call sys.set_lazy_imports('none') to force eager imports, but a library must not silently enable a global mode because it changes the caller's import timing. Global all belongs only in fully audited applications or frameworks.
Observe first-use latency and roll back
Record cold start, first resolution, steady-state execution, ImportError, circular-import, and missing-plugin events by subcommand and interpreter version. If first-use P95, error timing, or side effects regress, disable lazy imports and ship the compatibility build; keep ordinary imports as the safety baseline.
Model high-quality answer
“PEP 810 is explicit opt-in, not global magic. I would baseline importtime and mark only optional modules without required import-time effects as lazy. Critical configuration, plugin registration, and security checks stay eager; __lazy_modules__ provides Python 3.14 compatibility. Tests cover first-access errors, cycles, concurrent access, type checking, and --help, while metrics separate cold start from first-use P95. A none mode or feature switch provides rollback.”
Common mistakes
- Making every import lazy → critical effects and errors are delayed → choose optional, side-effect-safe modules.
- Measuring only cold start → first command latency worsens → measure first resolution and steady-state P95.
- Enabling global
allin a library → caller import timing changes → keep libraries normal and audit applications. - Ignoring Python 3.14 → older interpreters cannot parse the syntax → use
__lazy_modules__or an eager branch. - Replacing runtime tests with
TYPE_CHECKING→ actual first use can fail → run multi-version import and subcommand tests. - Removing the eager baseline → rollback becomes slow → retain ordinary imports and a kill switch.
Follow-up questions and answers
Follow-up 1: How does lazy import differ from an import inside a function?
Lazy import keeps the dependency declaration at module scope and resolves the object once on first access. A function import is an explicit runtime statement that may repeat lookup. Both move work into the runtime path, but their error and concurrency boundaries differ.
Follow-up 2: Why should plugin-registration modules stay eager?
If discovery registers plugins during import, laziness makes the plugin invisible until first access, breaking --list-plugins or route tables. Keep lightweight registration metadata eager and defer only the heavy implementation.
Follow-up 3: How do you test thread safety?
Have multiple threads or tasks access one lazy name simultaneously. Verify one initialization, repeatable exceptions, and no partial registration state; include a deliberately failing import fixture in CI.
Follow-up 4: What if Python 3.15 changes before final release?
Put interpreter versions, PEP 810 semantics, and key dependencies in a compatibility matrix. Enable the feature only in a controlled pre-release channel, then rerun import, startup, error-timing, and fallback tests for the final release.