Why prefer a try/except ImportError probe over a sys.version_info gate for optional features?

## The two questions are not the same question `sys.version_info >= (3, 14)` answers: *did the language release that this interpreter claims to implement ship the feature upstream?* What your code needs to know is: *can I import it, here, right now?* Those coincide most of the time, which is exactly what makes the gap dangerous — it is not visible in development and shows up in one deployment. Ways they come apart in production: - **A stripped-down runtime image.** Minimal images and vendored interpreters routinely drop parts of the standard library to save space. The version is right; the module is gone. - **A system package that splits the standard library.** Some platform packaging splits pieces of the stdlib into separately-installable OS packages; a container that installs only the base package reports a complete version number with holes underneath. - **Another implementation at the same language level.** It can report the language version faithfully while lacking a CPython-specific module or an accelerator. - **The module imports but the attribute you need does not exist**, because a function was added in a later patch release than the one you gated on. - **A backported provider on an older interpreter**, where the feature *is* available below your version floor and the gate needlessly takes the slow path. A probe has none of these failure modes, because it asks the environment the question the code actually has: ```python try: from concurrent import interpreters except ImportError: interpreters = None ``` Bind the result to a module-level name once, at import time. Probing inside a function that runs per work item pays the `sys.modules` lookup and the exception machinery over and over, and worse, it scatters the decision across the codebase instead of concentrating it in one line you can log. ## The failure that makes people careful about this An image-thumbnail worker gated an optional codec on a version comparison and wrapped its whole setup block in `except ImportError: pass`. On the build machine the primary path ran. In the deployed image the module was absent, the handler swallowed the error, and a fallback object stayed bound to a partially-initialised default that processed only the first chunk of each job. A 6,800-row batch came back as a silent truncation: no exception, no non-zero exit, just a shortfall nobody noticed until the counts were compared days later. Three things went wrong, and all three are avoidable: 1. **The gate tested the wrong proposition** — a release number instead of an import. 2. **The `try` block was too wide.** A broad `try` around several statements means an `ImportError` raised *inside* one of the imported modules — a genuinely broken dependency deeper down — is reported as "the optional feature is absent". Keep the block to the import statement alone. Where you specifically mean "not installed", catch `ModuleNotFoundError`, the narrower subclass of `ImportError`; a plain `ImportError` also covers "the module exists but a name inside it does not". 3. **The fallback was silent.** A degradation that emits nothing is invisible in production. Log the chosen path at startup, expose it in a health or version endpoint, and — if the fallback is not actually acceptable for the job — raise at import time rather than degrade. Failing loudly at start-up beats truncating output for a week. ```python import logging try: from compression import zstd except ImportError: zstd = None logging.getLogger(__name__).warning("zstd codec unavailable; using the slower codec") ``` ## Probing without importing `importlib.util.find_spec("compression.zstd")` returns `None` when the module cannot be found, and does so without executing it. That is useful when the import is expensive, or when you want to report availability without paying for the module. Note that finding a spec for a submodule imports the parent package, and that a spec being findable is not quite proof the import will succeed — the module body can still fail. When you are going to use the module anyway, importing it inside `try` is both simpler and stronger evidence. ## Where a version check is still the right tool The probe pattern has one hard limit: **syntax**. A module using a construct the running interpreter cannot parse raises `SyntaxError` at compile time, before a single statement of it executes, and no `except ImportError` anywhere will catch that. The standard answer is to isolate the newer syntax in its own module and gate the *import of that module* on a version comparison, or to ship separate modules per version floor. Version checks also stay correct for behavioural changes with no importable marker — the default `multiprocessing` start method becoming `forkserver` on Unix other than macOS in 3.14 is one such change: nothing new becomes importable, the default simply differs. The rule that survives: **probe for capabilities, compare versions for semantics.** And whichever you use, make the branch observable, and run both sides of it in CI. An untested fallback path is not a fallback; it is an outage with a delay on it.