Python 3.15 lazy imports: measure startup costs and test delayed failures

Start with commands that can skip backend work

Python 3.15.0 was released on October 9, 2026. It added explicit lazy imports that postpone module loading until an imported name is used. Applications can keep dependency declarations at module scope while deferring their loading cost, according to the release overview. For an AI command-line interface (CLI), that suggests a focused experiment: let static help and version output skip backend initialization. Sources: Python Insider, Python documentation

The proposed AI CLI lab has not been executed. It calls for command-specific testing rather than a general speedup claim.

Preserve deferred loading in the entry point

Build a small application named ailab with paths for static information, provider discovery, deterministic mock chat, and local embeddings. Put dependencies behind application-owned adapters and keep the package initializer minimal. Start with the mock backend. Then add a pinned embedding implementation after checking whether its dependencies install on the selected Python build. Record wheel and source installations separately from runtime results.

Use local wrappers for dispatch so constructing the argument parser does not immediately access every backend. The language reference permits explicit lazy imports at module scope. It excludes function bodies, class bodies, and try, except, and finally blocks. Accessing a lazily imported name loads its module; selecting a member does not restrict execution to that member. The proposed entry point below keeps backend access inside the selected command’s wrapper. Compare the variants in the following list while keeping the rest of the application unchanged. Sources: Python documentation

# Proposed lazy entry point
import argparse

lazy import ailab.chat_backend as chat_backend
lazy import ailab.embed_backend as embed_backend

def run_chat(args):
    return chat_backend.run(args)

def run_embed(args):
    return embed_backend.run(args)

# Register these local wrappers with the argument parser.
# Access the selected backend only after argument parsing.

1. Record an unchanged eager baseline on the released Python 3.15.0 interpreter.
2. Create an explicit lazy variant by changing only selected backend imports.
3. Create a function-local import variant for comparison. Sources: Python Insider

Measure startup and first use separately

Keep the interpreter, environment, dependency lock, and fixtures identical across the primary comparison. Time whole commands from the parent process to include interpreter startup. Add an explicitly flushed readiness marker, then instrument backend resolution and initialization separately. The table below defines the proposed measurement boundaries. Use them to check whether a faster readiness signal accompanies a slower first useful result.

Pre-create bytecode caches and describe the main experiment as fresh processes with warm filesystem caches. Warm up each scenario before collecting samples, and randomize variant order. Retain raw samples and exit codes. Report median and 95th-percentile latency with uncertainty, and investigate failed runs. Record the Python build, operating system, CPU, power settings, dependency versions, environment variables, and application commit. Run import tracing separately, pre-download model assets, and report setup time independently.

Benchmark mock chat before introducing model or network variability. For embeddings, separate import resolution, model initialization, first inference, and later operations in the same process. Publish absolute application latency alongside a bare-interpreter reference, even if the improvement is small.

Test dependency failures after readiness

Introduce a deliberately absent dependency using the fixture below. The language reference says loading errors surface when the imported name is first used. The lazy fixture should therefore print its readiness marker before failing, while an eager counterpart should fail before the marker. The release overview says delayed-error tracebacks include both the access location and the original import statement. Sources: Python documentation

# delayed_failure.py
lazy import ailab_missing_backend_fixture

def main():
    print("CLI ready", flush=True)
    ailab_missing_backend_fixture.run()

main()

Capture standard output, standard error, exit status, and any application state changed before failure. Catch expected optional-dependency errors around first access. Distinguish a missing backend package from a missing transitive dependency, and preserve unexpected exceptions. Test fallback behavior instead of translating every import failure into an installation suggestion. If readiness appears before essential initialization succeeds, decide whether that signal still meets its consumers’ expectations.

• Remove the selected backend and record the exception type and missing-module name.
• Remove a transitive dependency and check that diagnostics identify the actual failure.
• Inject a syntax error and a top-level RuntimeError in separate runs.
• Exercise a compiled dependency that cannot load and retain its platform-specific diagnostic.
• Leave the broken backend unselected and verify that unrelated commands remain usable.

Test discovery before accessing a provider

Provider discovery needs a separate correctness test. Use the application-owned fixtures below to check import-time registration before investigating any real AI dependency.

# provider_registry.py
PROVIDERS = {}

# demo_provider.py
from provider_registry import PROVIDERS

def complete(prompt):
    return "mock response"

PROVIDERS["demo"] = complete

# provider_probe.py
import provider_registry
lazy import demo_provider

print("before:", sorted(provider_registry.PROVIDERS))
demo_provider.complete("hello")
print("after:", sorted(provider_registry.PROVIDERS))

The expected first listing is empty, with demo appearing after direct provider access triggers loading. Then remove that direct access and make chat find its backend exclusively through the registry. This checks whether discovery can reach an implementation without depending on earlier test activity. Compare eager registration, an explicit idempotent registration function, and eager lightweight metadata that defers implementation loading. Verify complete provider listings, duplicate registration behavior, and repeated initialization for the chosen remedy. Sources: Python documentation

Set migration criteria on the final interpreter

Retain the unchanged eager baseline as the primary control.

Check initialization context as well as latency. Exercise worker-thread access and module search-path changes wherever the application permits them. Require unchanged discovery, output, and exit behavior. Also require improved targeted commands, acceptable first-result and tail latency, and accurate dependency diagnostics. Run every command in a fresh process and publish exact versions and raw samples.