[Distutils] Patch to have distutils generate PYC *and* PYO files

[M.-A. Lemburg]

Greg Ward wrote:
> 
> 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.

It's not as expensive as it sounds... on my machine I can't even
notice a difference.
 
> 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.

Right. It should be possible by providing a helper in distutils
which is then used instead of py_compile.

> 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.

Right. I don't care about the RPM size at all: bandwidth is
there, harddisk's are cheap. Size is not as much an argument
anymore as it was some years ago.
 
> 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.)

Ah, you are forgetting about the few of us who have to make
a living by writing commercial closed source software, e.g.
my apps are only shipped with PYO files with doc-strings stripped.

Most of the underlying helpers are Open Source though, ie.
the mx Extensions were written for just this purpose -- not
only to get a warm fuzzy feeling from community feedback ;-)
 
> 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.)

Hmm, the existing logic works just fine -- why change it ?

> > 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.

But it does support -O and -OO -- which is what Python
itself uses. Wouldn't that be an option ?

If not, I'd also be satisfied with --optimize=0|1|2 without
default value.

> I think this is a frill compared to figuring out when to compile and how
> to get both .pyc and .pyo in there, though.

Not necessarily... some people might not want to get doc-strings
into production code.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/