Would you not also have to remove sys.set_lazy_imports("none") for the same reason?
I’m OK with leaving the rest of the filter system in place, as it’s reasonable to argue that anyone using sys.set_lazy_imports_filter is deliberately choosing to rely on implementation details of the modules being forced to load eagerly, and therefore there’s no need to try to document for every single module whether it’s “safe to force eager loading”. The key difference with the “none” forms is that they don’t have an “escape hatch” - it’s all or nothing.
Anyone who really wants to force all imports to be eager can still do sys.set_lazy_imports_filter(lambda *args: False) - and that form makes it very clear what you’d change if you needed to add an exclusion list of modules that could be imported lazily.
Also, isn’t -X lazy_imports=all just as problematic? Maybe the stdlib doesn’t break in that case[1], but after all, isn’t it doing precisely the same as PEP 690 proposed, making all imports lazy, which was rejected because it would cause a split in the community over whether import-time effects are allowable? If the argument that “projects will need to support -X lazy_imports=none, otherwise we’ll just have a broken option” just as applicable to the “all” case?
To put this another way, I’m hesitant to single out the stdlib here. It’s an important special case, but it’s far from the only case of widely used library code.
Do we test that? ↩︎