On 28.09.2021 14:26, Filipe Laíns wrote: > On Tue, 2021-09-28 at 10:22 +0200, Marc-Andre Lemburg wrote: >> On 27.09.2021 18:51, Eric Snow 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? >> >> #3 sounds like a good solution, but how would you detect "running >> from the source tree" ? This sounds like you need another stat call >> somewhere, which is what the frozen modules try to avoid. > > It does. FYI, here's the sysconfig implementation > https://github.com/python/cpython/blob/main/Lib/sysconfig.py#L146-L181 > > But a more efficient way to do this could be added.
Thanks. So the Setup files are used as landmarks to determine whether Python is from a Python source tree or not. >> I'd like to suggest adding an environment variable to enable / >> disable the setting instead. This makes it easy to customize the >> behavior without introducing complicated logic. >> > > From your followup reply, it seems like you are suggesting that it should be > enabled by default, and use a env var to disable it. That would have the same > problem regarding the annoyance of contributors. Setting an env var in a dev environment is not really all that hard (I always have such environments set up for all the projects I'm working on), so it's only a mild annoyance, while not affecting all other times Python is run by others. The env var would also have the nice side effect of not cluttering up the command line and making it easy to test drive frozen vs. source code based imports. > Is there any reason why you would prefer that over #2? That seems like the > best > option to me if #3 is not feasible. PGO optimizations have to be enabled with ./configure and are not enabled per default, so it's rather likely that many Python binaries out there do not have PGO enabled and would then not benefit from the frozen modules -- even though PGO is not required for supporting frozen modules. I don't think combining the two features is a good idea. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 28 2021) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/SKDBB3XN2FNWTIVDTOBFLEJXUFAWG6IO/ Code of Conduct: http://python.org/psf/codeofconduct/
