[Distutils] reservations about pythonv

Brandon Craig Rhodes brandon at rhodesmill.org
Wed Mar 16 17:21:36 CET 2011

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   brandon at rhodesmill.org   http://rhodesmill.org/brandon

More information about the Distutils-SIG mailing list