I suspect that the current "pythonv" proposal should not become how virtualenv is implemented in the future.
The proposal would add another exec() to every invocation of Python in the virtualenv. Not only is exec() among the most costly system calls on Unix systems, but it is even slower on Windows. Furthermore, the re-exec() will generate significant noise and annoyance - if not outright breakage - when people use binary tools like gdb and valgrind, because MYENV/bin/python will become a binary that looks nothing like the Python binary (none of the usual symbols, binary dependencies, and so forth) and that disappears almost immediately after being run and is replaced with a completely different binary. Do all popular binary debugging tools handle an exec() cleanly? At the very least everyone's debugging practices and scripts would have to be re- worked to ignore the stats and results that came back from that first ephemeral "pythonv" process image. I certainly agree with everyone that Python 3.3 should natively support a virtualenv mechanism, but I think that it should be the full "python" that gets copied. I realize that this means that the "python" binary will not get updates when the system Python does; but isn't the whole idea of a virtualenv that it insulates me from change in a way that using the system Python does not? I would be quite happy for either the "activate" script (or Python itself?) to issue a warning if the binary in the virtualenv has fallen behind the image in the system Python. -- Brandon Craig Rhodes bran...@rhodesmill.org http://rhodesmill.org/brandon _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
