On 5/4/2012 11:58 PM, Glenn Linderman wrote: > On 5/4/2012 8:48 PM, Terry Reedy wrote: >> CPython is developed, tested, packaged, distributed, and installed as >> one unit. It is intended to be run as one package. If something caches >> a copy of python.exe, it seems to me that it should check and update >> as needed. Could venv check the file date of the current python.exe >> versus that of the one cached, much like is done with .pyc compiled >> code caches? > > I almost wrote this response (using different words, but the same idea) > but concluded that: > > 1) Python wouldn't run far without its standard library, so a venv check > would have to be very early, and likely coded in C, and therefore > probably has to be part of Python.exe > > 2) If it was not part of Python.exe, it would have to work similarly to > the launcher, and there would be yet one more process sitting around > waiting for Python to exit (on Windows, where there is no exec). > > So I concluded that probably Python.exe needs to make the check, but if > it is aware it existing in venv, it might be able to put out a better > message than "just" the mismatch between exe and lib; or at least the > message should mention the possibility of an old venv cache. The gist of my response is that the venv 'tail' should way the python 'dog' as little as possbile. I also wonder how often such incompatibility occurs. Optionally changing the de facto semantics of CPython's built-in dict in bug-fix releases was a rather unique event. I am sure we would all be happy to never have to do such again. -- Terry Jan Reedy
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