The venv module does not evenly create the necessary binaries/symlinks when building virtualenvs. If you call venv like this:

seliger@core:~/venvs$ python3 -m venv venvA

seliger@core:~/venvs$ ls -l venvA/bin/
total 32
-rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate
-rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh
-rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish
-rwxrwxr-x 1 seliger seliger  254 Dec 28 21:29 easy_install
-rwxrwxr-x 1 seliger seliger  254 Dec 28 21:29 easy_install-3.5
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip3
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip3.5
lrwxrwxrwx 1 seliger seliger    7 Dec 28 21:29 python -> python3
lrwxrwxrwx 1 seliger seliger   16 Dec 28 21:29 python3 -> /usr/bin/python3

...you do not end up with a "python3.5" binary. 

However, if you call venv like this:

seliger@core:~/venvs$ python3.5 -m venv venvB

seliger@core:~/venvs$ ls -l venvB/bin
total 32
-rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate
-rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh
-rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish
-rwxrwxr-x 1 seliger seliger  256 Dec 28 21:29 easy_install
-rwxrwxr-x 1 seliger seliger  256 Dec 28 21:29 easy_install-3.5
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip3
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip3.5
lrwxrwxrwx 1 seliger seliger    9 Dec 28 21:29 python -> python3.5
lrwxrwxrwx 1 seliger seliger    9 Dec 28 21:29 python3 -> python3.5
lrwxrwxrwx 1 seliger seliger   18 Dec 28 21:29 python3.5 -> /usr/bin/python3.5

...you DO get the necessary python3.5 binary. Some vendors are making it a requirement to call a specific pythonX.Y binary to ensure compatibility. One such example is the serverless framework when deploying to Amazon Web Services. Another example is the useful pyenv utility that manages full Python builds and virtualenvs. When it depends upon venv, it exhibits the same behavior. I submitted a patch workaround to force calling venv using pythonX.Y, but this really seems like an issue with the venv module itself.

The expected behavior should be that venv generates all three binaries (python, python3, and python3.5) regardless of how the python command was invoked.

I am able to reproduce this on Python 3.5 and 3.6. I could not find any other similar references in searching the bug system.