> [Guido] > > I was watching file modification times on my Windows box (strange > > hobby, I know :-), and I noticed that after a fresh install of Python, > > the .pyc files seem to be written when the first code that imports the > > corresponding module runs, rather than all of the .pyc files being > > compiled at once by the installer. Wasn't there code in the installer > > that precompiles all modules? [Tim] > Not in the PLabs Windows installer, no. > > > I know the Unix install does this, and I vaguely remember that the > > Windows installer did this too -- or was it only the Win32all > > installer??? > > Probably the latter, then. > > > If there's code to do that in the Windows installer now, it seems it's > > not working. > > There isn't, so it's working fine <wink>. OK, so maybe I was hallucinating. > > If there isn't such code, perhaps there should be? > > Why? Not that increasing installation time and disk consumption aren't > worthy goals ... If this isn't done, a problem might be (and this is why this is always done on Unix) that if the user who installs Python has more privileges than the user who uses Python, the user who uses Python may not be able to write the directory containing .pyc files, so they end up recompiling all modules each time they are loaded. I expect this will be more of a problem as typical Windows users and installations (e.g. XP) become more security aware, software is installed by Administrator, and users don't have Administrator privileges. I guess the way to implement it (and I believe Mark Hammond did indeed do this for win32all) is to run Python near the end of the installer with the compileall.py script as an argument. Feeling-quite-the-Windows-XP-expert-lately, --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4