[Harry Henry Gebel, regarding his patch for doing both optimized and non-optimized bytecode compilation at install-time]

Hi here are the changes made by the patch:

In install_lib.py:

Puts --optimize option to work (see below) Adds two negative options --no-compile and --no-optimize which turn off --compile and --optimize . No longer attempts to set compile and optimize from --compile-py and --optimize-py in 'install' (there are no such options). Runs 'build_clib', eliminating the need for 'install' to run 'build' [...]

I like the spirit of the patch, but I'm not sure if this is the right way to do it. I'm inclined more towards this: generate a little script, and run it twice: "python compile.py" and "python -O compile.py". I see three options: 1) generate a script that explicitly lists all the .py modules to be compiled, does the necessary timestamp-checking, and calls 'py_compile.compile()' to do the compilation. PRO: gives us exact control over what's compiled CON: largely reimplements the standard compileall module (the difference is that this one would take a list of files rather than a directory) 2) run python <pythonlib>/compileall.py -d <install_dir> PRO: not much code to write CON: not the right thing to do if installing new modules into a package (eg. the root package) that already has modules in it 3) same as #2, but invoke "compileall" as a "-c" script -- eg. python -c "from compileall import compile_dir ; compile_dir(<install_dir>) ...I don't think this is any different from #2 I'm leaning towards #1, but with a new Distutils module to handle most of the work (ie. the near-reimplementation-of-compileall). Thus, the generated script would be mainly a list of modules. Perhaps we could even get away with generating just a data file (list of modules to compile) and passing it to the new "distutils.bytecompile" (?) module. Opinions? I'm really not keen on the Distutils recursively invoking the setup script just to do bytecode compilation. *Really* not keen. And it seem more symmetric to not care what the current interpreter's optimization state is, but just spawn two separate interpreters to take care of the two optimization case. Also, as I mentioned in private email to Harry, I don't think it's the business of the "install" command to know what the subcommands of "build" are, so I'd prefer if you left out the "don't run 'build', just run its subcommands" tweak. Harry, d'you want to rework and resubmit your patch? If not, I'll tackle this task. Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ A day for firm decisions!!!!! Or is it?