>>>>> "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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4