Fix dependence on system python being python3

[jgkamat]

All of my systems 'python' executable defaults to python2. Per PEP-394, distributors can choose which version of python the python binary points to, and since this project requires python3, it must use the python3 binary to ensure it gets a version of python3.

[po5]

python3 may not be available on all systems, this is going to fix it for some and break it for many others.
If I care about that, I'll make the python path an option (and still default to python).

[rydalt]

You can reasonably assume python3 is available due to PEP 394, it specifies python3 should link to python3.x. Until recently it was actually the case that python was supposed to invoke Python 2

The python command should always invoke Python 2

Now it's the maintainers choice what python invokes, be it Python 2, 3, nothing, or ask the user what they want it to do. Before that, the only distro I know that had python invoke python3 with Python 2 present was Arch Linux. Debian, Ubuntu, CentOS, and many others I'm sure all defaulted and continue to default to python2.

[jgkamat]

python3 may not be available on all systems, this is going to fix it for some and break it for many others.

It's actually the other way around per PEP-394. Maintainers can opt to not provide a python binary at all, link to python2 or link to python3. If python3 is available through python, by that definition, there must be a python3 binary to link to.

As it stands, this script is broken on the vast majority of machines out there.

[po5]

This doesn't apply to Windows users, I'll focus on handholding them. That said, I could very well just detect if the OS is Windows and set the default to python or python3 accordingly.

That seems like the best solution to me, will implement it when I can.

[jgkamat]

This doesn't apply to Windows users, I'll focus on handholding them.

Per the link you provided, windows dosen't seem to have a standard, so this script may not work both ways. For example, per PEP 397

As a concession to interactively launching Python, the launcher will support the first command-line argument optionally being a dash ("-") followed by a version qualifier, as described above, to nominate a specific version be used. For example, while "py.exe" may locate and launch the latest Python 2.x implementation installed, a command-line such as "py.exe -3" could specify the latest Python 3.x implementation be launched, while "py.exe -2.6-32" could specify a 32bit implementation Python 2.6 be located and launched. If a Python 2.x implementation is desired to be launched with the -3 flag, the command-line would need to be similar to "py.exe -2 -3" (or the specific version of Python could obviously be launched manually without use of this launcher.) Note that this feature can not be used with shebang processing as the file scanned for a shebang line and this argument must both be the first argument and therefore are mutually exclusive.

I don't have a windows key to check, but I would imagine python.exe would default to python2, python3.exe would default to python3, and python wouldn't be available at all (since that breaks executable naming conventions on windows).

[rydalt]

I just decided to test, python3.exe works on Windows and python.exe executes python3.exe. Mind you I don't have Python 2 installed as nothing requires it, Windows Python devs tend to compile their programs into .exe's so you don't actually need to install Python 2 or 3 typically.

Also python invokes python.exe and python3 invokes python3.exe.

[po5]

That's not how windows executables work at all, you don't have to specify the .exe.

Please don't try to lecture others when you've got no idea how something works.

Will implement the solution discussed earlier as it's seemingly the best we'll ever come up with.