[Python-Dev] Proto-PEP regarding writing bytecode files

[Skip Montanaro]

>>>>> "Brett" == Brett Cannon <bac@OCF.Berkeley.EDU> writes:

    Brett> [Skip Montanaro]
    >> Folks,
    >> 
    >> Here's a first stab at a PEP about controlling generation of bytecode
    >> files.  Feedback appreciated.
    >> 

    Brett> Now I don't need to worry as much about summarizing this thread.  =)

    Brett> <snip>
    >> Issues
    >> ======
    >> 
    >> - When looking for a bytecode file should the directory holding the
    >> source file be considered as well, or just the location implied by
    >> PYCROOT?  If so, which should be searched first?  It seems to me that
    >> if a module lives in /usr/local/lib/python2.3/mod.py and was
    >> installed by root without PYCROOT set, you'd want to use the bytecode
    >> file there if it was up-to-date without ever considering
    >> os.environ["PYCROOT"] + "/usr/local/lib/python2.3/".  Only if you
    >> need to write out a bytecode file would anything turn up there.
    >> 

    Brett> In other words you are wondering about the situation of where
    Brett> root installs Python (and thus generates .pyo files in the
    Brett> install directory) but PYCROOT is set later on.  Seems reasonable
    Brett> to check the holding directory, just don't know how often this
    Brett> situation will come up.  But if you are going to all the trouble
    Brett> of having a separate place to keep your byte-compiled files,
    Brett> shouldn't you keep *all* of the byte-compiled files you want to
    Brett> use together?  Since you are storing them it is a one-time
    Brett> compile and thus not that big of a deal.

Here's a situation to consider: Shared .py files outside the normal
distribution are stored in a read-only directory without .pyc's.  Each user
might set PYCROOT to $HOME/tmp/Python-N.M.  A single version of those files
could be safely shared by multiple installed versions of Python.  You might
always search the directory with the .py file, then the private repository.

Or did I misunderstand what you were getting at?

    >> - Runtime control - should there be a variable in sys (say,
    >> sys.pycroot) ...

    Brett> Why the heck would your needs for compiling bytecode files change
    Brett> while running a program?  

I don't know, but there is a compile() builtin, so people might want to
control its behavior.  Maybe pychecker wants to compile modules without
dropping .pyc files on the disk which it needs to clean up later, even in
the face of the user's PYCROOT setting.  It could simply set sys.pycroot at
startup.  Of course, it could also putenv("PYCROOT", "/dev/null") as well.
I guess it's mostly a matter of convenience.  (Also, sys.pycroot won't
affect forked subprocesses.)

Skip