I do have a slight concern with the ‘global lazy imports flag’ (
-X lazy_imports=...)
It’s explicitly an advanced/opt-in mode (as well as the opt out). Default behavior stays fully explicit; nothing becomes lazy unless you ask for it. We will surely brand it as such: an advanced feature that has a lot of potential for a subset of users but in the PEP it’s important but secondary.
… which seems to me to stand in opposition to the explicit aspect of the new
lazy import ...syntax…
We’ll brand and document it as an advanced switch, not a routine performance knob. It’s advertised, not hidden, and the docs will stress what is the usage mode and when not to use it.
… I worry that this will become a hidden secret hack ™ that will proliferate as a….
Docs will make the trade-offs clear: if you enable the global mode, you’re expected to use the filter and own exclusions. It’s fine for maintainers to close reports that only fail under -X lazy_imports=enabled without a minimal repro using explicit lazy. This is not really a problem: maintainers can simply decide what they support. If users open issues saying “your library could support this better,” that’s just information: you can close it if you don’t want to invest, or act on it if you do. As a maintainer myself, I don’t see harm in users surfacing that feedback, and we’ll make sure the docs hammer home that enabling the flag means you accept those trade-offs.
… Would it be going to far to make this an opt-in build time (
configure) option…
We’ll include strong warnings and guidance. A build-time gate it’s possible but honestly feels unnecessary (we don’t prevent users by default to have access to ctypes just because we think is advanced and potentially dangerous). Not having it would hinder a set of users that have big applications and the ones with large deployments (Meta, HRT, Google, and many others) that want to enable it broadly and tame it via the filter to realize startup/memory wins.
“What about support and tooling?” (bonus)
We’ll ship examples and rollout recipes, and there’s incoming open-source tooling that Meta is using to help generate/manage filters so users can safely exclude modules with import-time side effects. This will build on the PEP but is out of scope of the discussion.