Could an admin take this submission down or flag it?
Why this blew up just today is very surprising to me.
As a developer I’m annoyed with having to install third party packages to get access to Python 3. The software Apple ships is also code-signed, which is important to some organizations which relies on binary whitelisting (e.g. github.com/google/santa). Software from Homebrew or Anaconda are typically not code-signed.
I was hoping that perhaps bringing the old Python 2 interpreter up here could lead to more radars for the inclusions of a recent Python 3.x release in the base system.
To add one more entry to sslalready's list:
Don't know if you consider Manjaro just an Arch derivative, or not-major (despite being the most popular distro on Distrowatch), but Manjaro also ships with Python3 (to be more exact - Python 3.7) as a base.
Python 3.7.0 (default, Jul 15 2018, 10:44:58)
[GCC 8.1.1 20180531] on linux
Type "help", "copyright", "credits" or "license" for more information.
% /usr/bin/python -V
That they aren’t shipping 2.7.15 is kind of egregious.
I ignore system python entirely and roll my own, but cluttering up the system with old code from day 1 isn’t great.
The concept of default installations of tools has always been awkward. Invariably, to create a stable system around your software you want to control versions so that you can have predictable results.
I find Nix very appealing (though haven’t used it yet) in this regard. Similary, it’s why we’ve started using Docker to package up all the dependencies we need around the software.
A question I have is: should Apple just say, this is a tool for the OS only, and expect users to install the dependencies they need? Maybe even support that by adopting something like the Nix package manager for common dependencies across applications?
Usually, there are alternatives to these former GPLv2, now GPL3 tools and I wonder why Apple just does not replace them.
It took a long time for Red Hat and Canonical because a lot of the OS was written in Python 2.x, but Apple doesn't have that excuse.
I wouldn't be surprised if Apple just stays on Python 2 forever. Apple already does some patching to their copy of python when they upgrade OS, and it would require a fairly small amount of manpower to keep Python 2 running forever.
Apple would break compatibility if it removed Python 2, which it could do, if they really wanted.
Maybe for e.g. RHEL it makes sense to maintain Python 2 beyond end of life, since they can charge an arm and a leg for companies who have been too lazy or complacent to port and upgrade their stuff, despite clear and generous deprecation timelines. But I don't buy this for Apple.
There are many pieces of software (bash and clang as major examples) where Apple keep custom branches, often of otherwise unsupported versions.
I'm writing this on a MacBook Pro that was released with a CPU one full generation behind its competition.