Use python3 as default executable for x.py

[Mark-Simulacrum]

It seems that most distributions do not symlink python3 to python by default, as
was expected when adding this code. We still support python 2.7, but the default
is python 3, so reflect that here as well.

Fixes #71818

r? @cuviper to confirm my logic here is sound

[petrochenkov]

Python installation on Windows, on the other hand, doesn't have python3 at all.

[Mark-Simulacrum]

Hm, @petrochenkov -- does "python" work on Windows? Maybe we should hold off on this and try to do a survey of our options... I'm not sure.

[petrochenkov]

@Mark-Simulacrum
Here's how the Windows installation of Python 3 looks:

C:\>dir /B Python38
DLLs
Doc
include
Lib
libs
LICENSE.txt
NEWS.txt
python.exe
python3.dll
python38.dll
pythonw.exe
Scripts
tcl
Tools
vcruntime140.dll

[mati865]

Is #!/usr/bin/env python even parsed by non MSYS Python on Windows?

[petrochenkov]

@mati865
Well, if non-MSYS2 Python is run from MSYS2 shell (this is what I do), then it is parsed.

$ ./x.py
/usr/bin/env: ‘python12345’: No such file or directory

Moreover, if the non-MSYS2 python is not found, then we proceed to MSYS2 python which is subtly incompatible with x.py (this is even mentioned in README).

Looks like the shebang indeed doesn't affect people working from cmd or powershell , but why would anyone do that.

[petrochenkov]

To clarify, this is an easily resolvable problem, you can manually create a symlink named python in C:\Python38, but same applies to Ubuntu with python-is-python3 package which people are "encouraged to install".

[cuviper]

PEP-394 covers python for Unix-like systems, but still allows it to go either way, or not exist at all. It does at least specify that python2 or python3 should exist for their respective installations. Windows is separate in PEP-397, but doesn't really clarify this point to me, and hasn't been updated since 2011 anyway. The interpreter tutorial says that the Windows Store version of Python has a fully versioned name though.

Fedora has a python-unversioned-command subpackage for the python symlink, which didn't move to python3 until Fedora 31, per the change "Python means Python3".

I think leaving the shebang with python makes sense, and if you need something different you can invoke my-python x.py. The default for config.toml can be more nuanced, seeking probably in the order of python3, python, or python2.

[Mark-Simulacrum]

Hm. We currently default python in config.toml to whatever invoked x.py -- I think that makes sense; no one should really be invoking bootstrap (the binary) directly.

[cuviper]

We currently default python in config.toml to whatever invoked x.py -- I think that makes sense;

I agree, that's a solid choice.

I'm not sure what we need then -- better documentation of this nuance in the build requirements?

[Mark-Simulacrum]

Yeah, I think documenting that we use python in x.py's shebang, and noting that if you don't have that available running x.py with whatever python you have locally installed is the way to go. I'm not sure how to phrase that though so I'm going to go ahead and close this PR -- maybe someone can propose wording in a PR.

[iago-lito]

@Mark-Simulacrum What about

# Python 2.7 deprecation in favor of Python 3.x
# has led to inconsistencies among distributions
# that are still unresolved
# regarding the name of the binary `python` file.
# For instance, some distributions stick to using
# `python3` vs. `python2`,
# while others don't have those
# and only refer to `python`.

# As per #71841, `x.py` shebang line refers to `python`.
# Should this not work on your platform when you run `x.py`,
# the easiest solution is to call `your_python x.py` instead.

Not sure where to put it or how to propose a proper PR, though :(