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

[Brett Cannon]

[Skip Montanaro]

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

OK, but how are they going to specify that universal read-only directory?
Is it going to be set in PYTHONPATH?  If so, then you still don't need to
check the directory where the module exists for a .pyc file since it was
specified in such a way that checking there will be fruitless.  Same goes
for if you set this read-only directory in sys.path.

> Or did I misunderstand what you were getting at?
>

No, I think you got it.

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

I agree that it is a matter of convenience and I just don't see it being
enough of one.  -0 vote from me on this feature.

-Brett