On 20 September 2000, M.-A. Lemburg said:
Attached you find a patch against the current CVS tree which allows distutils to include PYC as well as PYO files.
Looks like it should work, but I really don't like the idea of spawning an interpreter for *every* *single* *file* we want to compile. This sounds very expensive. Doesn't look like it would be too hard to rework your 'compile()' function to work on a bunch of files at once, and the "install_lib" command already sorta-kinda works that way. The trouble is generating a single Python command that compiles an arbitrary number of scripts -- it's not impossible, just hairy. Maybe it's time to reconsider when we do byte-compilation. The reasons for doing it at install time were: * so the .py filename encoded in the .pyc file is correct * to make built distributions smaller But the former is a red herring, since it turns out that we do pseudo-installations to temporary directories to create RPM and wininst built distributions, and will probably do the same for other smart bdist formats. And the latter seems to be a lower priority than making what happens at install time as simple as possible. Most people (myself included) seem to be more concerned that an RPM come with "batteries included" (ie. .pyc and .pyo) files than that it be as small as possible. Byte-compiling at build time would also (I think) make it easier to distribute *only* bytecode, for those poor unenlightened souls who somehow think that keeping their source code to themselves will make the world a better place. (Obviously I disagree with those people, but I don't want to bar them from using the Distutils.) If we byte-compile at build time, then using the standard compileall module/script is a no-brainer: the build directory is purely the domain of this particular module distribution, so if we blindly walk over it compiling everything, that's just fine. (Doing that in the real install directory would be quite rude, which is why the current byte-compilation code doesn't use compileall.py.)
I haven't dug deep into the option system yet, but it would be nice if there also were an option which lets the packager set the optimization level she want to use for the PYO files.
I think the best way to do that would be to support something like build --optimize # .pyc and .pyo (level 1) build --optimize=2 # .pyc and .pyo (level 2) unfortunately, getopt (and therefore fancy_getopt) doesn't support default option values. ;-( So this would have to be something else, alas. I think this is a frill compared to figuring out when to compile and how to get both .pyc and .pyo in there, though. Greg