>> 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.
Brett> OK, but how are they going to specify that universal read-only
Brett> directory? Is it going to be set in PYTHONPATH? If so, then you
Brett> still don't need to check the directory where the module exists
Brett> for a .pyc file since it was specified in such a way that
Brett> checking there will be fruitless. Same goes for if you set this
Brett> read-only directory in sys.path.
I'm still not sure I understand what you're asking. At runtime you have no
way of knowing that (for example) /usr/local/lib/python2.3 will never
contain bytecode files. You really have to check there. In the latest
version of the pep (see below) I nailed down the reading and writing
mechanisms better. There are also more examples. If one of them doesn't
address this issue, please feel free to shoot me a concrete example which
demonstrates your concerns.
Brett> 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?
Brett> I agree that it is a matter of convenience and I just don't see
Brett> it being enough of one. -0 vote from me on this feature.
Another use of sys.pycroot (now called sys.pythonbytecodebase) occurred to
me. There is a fair amount of work necessary to see if the value of
PYTHONBYTECODEBASE (used to be PYCROOT) is valid (make the directory
reference absolute, check that it exists and is writable by the current
user). I propose that check should be performed once at program startup and
sys.pythonbytecodebase set accordingly. This also allows users to set a
relative directory for PYTHONBYTECODEBASE without worrying that it will
silently move around as the program changes its working directory.
I suppose sys.pythonbytecodebase could be forced to be read-only, but I see
no particular reason to limit it. Hopefully its length will discourage
people from modifying it without good reason. Thank the BDFL for that
name. <wink>
At any rate, I believe I incorporated everybody's suggestions (thanks for
the feedback) and checked it in as pop-0304 (the number David Goodger
assigned me). You can now grab it from CVS or view it online at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/peps/pep-0304.txt
More feedback is welcome. Once the uproar^H^H^H^H^H^Hfeedback dies down a
bit, I will look at implementing the idea.
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