This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients BTaskaya, Mark.Shannon, brandtbucher, brett.cannon, eric.snow, gvanrossum, larry, lemburg, nascheme, ronaldoussoren
Date 2021-08-28.02:08:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1630116532.55.0.556384842283.issue45020@roundup.psfhosted.org>
In-reply-to
Content
There should be a boolean flag that enables/disables cached copies of .py files from Lib/.  You should be able to turn it off with either an environment variable or a command-line option, and when it's off it skips all the internal cached stuff and uses the normal .py / .pyc machinery.

With that in place, it'd be great to pre-cache all the .py files automatically read in at startup.

As for changes to the build process: the most analogous thing we have is probably Argument Clinic.  For what it's worth, Clinic hasn't been very well integrated into the CPython build process.  There's a pseudotarget that runs it for you in the Makefile, but it's only ever run manually, and I'm not sure there's *any* build automation for Windows developers.  AFAIK it hasn't really been a problem.  But then I'm not sure this is a very good analogy--the workflow for making Clinic changes is very different from people hacking on Lib/*.py.

It might be sensible to add a mechanism that checks whether or not the pre-cached modules are current.  Store a hash for each cached module and check that they all match.  This could then be part of the release process, run from a GitHub hook, etc.
History
Date User Action Args
2021-08-28 02:08:52larrysetrecipients: + larry, lemburg, gvanrossum, brett.cannon, nascheme, ronaldoussoren, Mark.Shannon, eric.snow, brandtbucher, BTaskaya
2021-08-28 02:08:52larrysetmessageid: <1630116532.55.0.556384842283.issue45020@roundup.psfhosted.org>
2021-08-28 02:08:52larrylinkissue45020 messages
2021-08-28 02:08:52larrycreate