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