On 07.11.2017 18:34, Stephan Houben wrote:
One (smaller) suggestion on the PATH situation on Windows:

I noticed that Visual C++ Build Tools installs a number of  "Command prompts"
under its Start menu item, each of which starts a cmd.exe with appropriate PATH
set to the appropriate compiler (32/64 bits or ARM cross-compiler), and
assorted environment variables set to the appropriate include/library directories.

Could we do something similar for Python?

I.e., Install under the "Python 3.6" start menu an additional
"Python command prompt", which will
start cmd.exe with an appropriate PATH so that python and pip
run without further prefix.

That way, the installer still doesn't need to mess with global PATH and you can
easily have multiple versions of Python, each with their own
"Python command prompt" submenu.

At least for Windows users this would simplify the situation a bit.


This suggestion is no different from environemnt activation scripts of anaconda/pyenv/virtualenv -- without the other benefits of virtualenv.

IPython solves this by creating version-specific executables (even in Windows). I see no reason why executables of Python proper cannot do the same. In fact, the reason why Windows version went Py instead of this seems to rather be to solve a completely different problem -- the filetype association (when running a script via ShellExecute, it autodetects which Python version to invoke).

2017-11-06 23:53 GMT+01:00 Ivan Pozdeev via Python-ideas <python-ideas@python.org>:
On 07.11.2017 1:48, Chris Barker wrote:
On Mon, Nov 6, 2017 at 9:52 AM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
I know and you still:

- have to use py -m on windows, python3 linux, python in virtualenv...

can't you use python3 -m pip install .....

You can't. Windows versions don't create versioned executables. Got bitten with this myself.

...Maybe they should?
(This is python-ideas, after all ;-) )


Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/