A couple of questions. If you’re planning a runtime -X option, then does that mean that the modules will be frozen at build time but Python will decide at runtime whether to use the frozen modules or the unfrozen ones? Are you planning on including the currently frozen importlib modules in that same mechanism? Will `make test` and/or CI run Python with both options? How will we make sure that frozen modules (or not) don’t break Python? Option #3 seems like the most reasonable one to me, with the ability to turn it on when running from the source tree. -Barry
On Sep 27, 2021, at 09:51, Eric Snow <ericsnowcurrently@gmail.com> wrote:
We've frozen most of the stdlib modules imported during "python -c pass" [1][2], to make startup a bit faster. Import of those modules is controlled by "-X frozen_modules=[on|off]". Currently it defaults to "off" but we'd like to default to "on". The blocker is the impact on contributors. I expect many will make changes to a stdlib module and then puzzle over why those changes aren't getting used. That's an annoyance we can avoid, which is the point of this thread.
Possible solutions:
1. always default to "on" (the annoyance for contributors isn't big enough?) 2. default to "on" if it's a PGO build (and "off" otherwise) 3. default to "on" unless running from the source tree
Thoughts?
-eric
[1] https://bugs.python.org/issue45020 [2] FWIW, we may end up also freezing the modules imported for "python -m ...", along with some other commonly used modules (like argparse). That is a separate discussion. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4ESW3NNO... Code of Conduct: http://python.org/psf/codeofconduct/