Well trying to test out venv on Python 3.3.2 on Linux Mint 16 x64 I was not able to get pip to execute correctly after it had been installed. The error from bash is:

(venv) wolfrage@wolfrage-KGP-M-E-D16 /media/ShareDrives/HomePlus/Jordan/Projects/The Strategist $ pip install pysdl2
bash: /home/wolfrage/Projects/The Strategist/venv/bin/pip: /home/wolfrage/Projects/The: bad interpreter: No such file or directory

Same exact setup procedures in a path with out any spaces works as expected:

(venv) wolfrage@wolfrage-KGP-M-E-D16 /media/ShareDrives/HomePlus/Jordan/Projects $ pip install pysdl2 --allow-external pysdl2 --allow-unverified pysdl2
Downloading/unpacking pysdl2
  pysdl2 is potentially insecure and unverifiable.
  Downloading PySDL2-0.8.0.zip (1.1MB): 1.1MB downloaded
  Running setup.py (path:/media/ShareDrives/HomePlus/Jordan/Projects/venv/build/pysdl2/setup.py) egg_info for package pysdl2
    
Installing collected packages: pysdl2
  Running setup.py install for pysdl2
    
Successfully installed pysdl2
Cleaning up...
(venv) wolfrage@wolfrage-KGP-M-E-D16 /media/ShareDrives/HomePlus/Jordan/Projects $ python3
Python 3.3.2+ (default, Oct  9 2013, 14:50:09) 
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sdl2
>>> exit()

I hope that this can be fixed prior to 3.4 being released.
This not only affected pip but easy_install too.

Due to the way the shell or kernel parses the shebang, you can’t have spaces in the path to the interpreter:

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

The solution is to separate your virtualenv from the directory containing your code.  (virtualenvwrapper works in that way for example.)  virtualenv’s job is to have a copied Python with an isolated site-packages; it does not matter whether the Python is in your project directory (./bin/python) or anywhere else (~/venvs/strategist/bin/python).

Wow that is a very compelling argument that I am hesitant to raise a counter point against. But I feel I would at least like to understand better. 
So why does this issue not affect the interpreter in the venv itself, only pip and easy_install, or other such tools with-in the venv? It seems to me that the activate script gets around this somehow for the interpreter, as it ran fine in the directory with a space in the name. Is it possible to apply the same fix action to at least pip since it will be included in venv once 3.4 is final, for a better user experience, or at least less user complaints?

In the meantime, I will fix my directory to use underscores instead of spaces. Thank you for your time.

The interpreter is a compiled C binary, not a shell script.  Thus the limitations of the !# "hack" do no apply to the interpreter itself.

s/shell script/script/

(A python script is not technically a "shell" script, but it uses the same !# mechanism to launch the binary (the interpreter) that reads the contents of the file and executes it.)

> Wow that is a very compelling argument that I am hesitant to raise a counter point against.

I was not making an argument to describe a choice made by Python developers, but describing how unix shells have been working for the last decades.  The behavior you observe is not related to Python at all, so it’s not in our hands to change for 3.4 or any future version.

> So why does this issue not affect the interpreter in the venv itself, only pip and easy_install, or
> other such tools with-in the venv? It seems to me that the activate script gets around this somehow for
> the interpreter, as it ran fine in the directory with a space in the name.

If I understand correctly, you mean that after activating a venv, you can type “python” and get the venv’s Python to run, but you if you type “pip” you get the error message about the space in the path.  The difference here, to expand RDM’s reply, is that more things happen when you run pip.

When you run “python”, the system splits the PATH environment variable on “:”, walks each dir found to see if their is an executable file named “python” there, and when found, runs it (it’s compiled code that can run directly).  This works because the paths in PATH are separated with a colon, so one path can contain spaces.

When you run “pip”, the steps above are done, then the shebang system is invoked: the pip file is not a binary executable but a script (text) file, so the shell or kernel will use another program to run that script, the shell by default or another program specified shebang.  A shebang is defined as “#!” + optional space + path without spaces + arguments (not supported by all systems).  That’s the issue here.

another program specified shebang → another program specified using a shebang