On Tue, Sep 28, 2021 at 6:36 AM Victor Stinner
Honestly, for me, #1: always on, is the most reasonable choice.
I dislike when Python behaves differently depending on subtle things like "was it built with optimizations" or "is Python started from its source tree"?
When I built Python without optimization and/or from its source tree, I do that to debug an issue. If the bug goes away in this case, it can waste my time.
So I prefer to teach everybody how to use "-X frozen_modules=off" if they want to hack the stdlib for their greatest pleasure. I prefer that such special use case requires an opt-in option, the special use case is not special enough to be the default.
Agreed. I just don't want to discourage potential contributors nor waste anyone's time. I suppose that's the fundamental question I originally posted: would it be too annoying for contributors if we made the default "on" always? I expect most non-docs contributions are made against the stdlib so that factors in.
It means that the site module module can no longer be "customized" by modifying directly the site.py file (inject a path in PYTHONPATH env var where the customized site.py lives). But there is already a supported way to customize the site module: create a module named "sitecustomize" or "usercustomizer". I recall that virtualenv likes to override stdlib site.py with its own code. tox uses virtualenv by default. Someone should check if freezing site doesn't break virtualenv and tox, since they seem to be popular in Python. The venv doesn't need to override site.py and tox can use venv if I recall correctly.
If site.py customization is too popular, I would suggest to not freeze this one, until the community stops doing that.
Good point. I'll look into that. -eric