"Ship with" is a bit too ambiguous for my taste. F28/F29 "ship with" Python 2 in the sense that the packages are there, just not installed with a default install. If you `dnf install python2` (or something that depends on Python 2.7) it will get installed. They've also gone through the effort and moved the system stuff line dnf to Python 3.
First, This is about RHEL 8 (Beta) not 7, 6, etc. Second `#!/usr/bin/python` is a different animal than `#!/usr/bin/env python`. One is hard coded. The other is `PATH` based so will change depending on current `PATH`.
On RHEL 7 (and earlier) `/usr/bin/python` must be the Python 2 the system shipped with or your break `yum` and other admin tools. When people try to install their own python by doing a `make install` as root, `yum` breaks and it's hard to recover the system.
What the article is saying is that RHEL 8 addresses this by having a platform python that the system tools use. So RHEL 8 tools will not use /usr/bin/python
CoolGuySteve complained that things will break because existing scripts assume /usr/bin/python. CoolGuySteve is correct. There is an enormous amount of work involved in changing or removing the function of /usr/bin/python.
Offering advice about how to write new software does nothing to help with the frustration he highlighted: His existing build systems will break. Build systems are especially frustrating as they tend to have hacked-together code that no one really wants to look at.
People will often work around this by installing a python2 as /usr/bin/python. At the end of the day this change results in a less predictable platform. On previous RHEL systems I know what /usr/bin/foo is -- it's predictable given the major version of the distro. But now I won't know what /usr/bin/python is on RHEL8. It will be uniquely different and that's not a good thing.
#!/usr/bin/env python is almost guaranteed to give you a surprise at some point. If someone has a virtualenv or conda env active in that shell it will be a different python environment (with different installed modules) than in other shells.
At least in the build-system glue language use case, the 'batteries included' modules like os, sh, glob, etc will all be there.
Similarly, if you require pandas like I do, there's a fairly comprehensive baseline of functionality you can expect regardless of what environment it comes from.
I've been puzzled about Kona for a while, since I don't really see a purpose for it. K/Q is specifically intended as a very high-efficiency language, and Kona doesn't say anything about benchmarks.
The original reason may have been that k3 was not open source and the free version was limited. But in general people write these things for all sorts of reasons. Just as there are dozens of Scheme interpreters.
