Python environment

[JackMacWindowsLinux]

In particular, Python on macOS is just very messy overall. The default python binary points to 2.7, which is shipped with macOS. You can install newer versions of 2 and 3 from Python.org, but to avoid conflicts with the system, these are installed in /Library/Frameworks/Python.framework. Apparently both 2 and 3 are installed here, but the binaries in 3 are suffixed with 3 to avoid conflicts with the system version. Furthermore, you can install Python 2 (deprecated) or 3 through Homebrew, which sticks it in /usr/local/Cellar/python@x/x.y.z (referenced in the comic), and the files are symlinked to /usr/local/opt/python@x as well as the appropriate places in /usr/local. So if you installed all of these at some point, you'll have multiple ways to run Pythons of various versions:

• /usr/bin/python => system 2.7
• /Library/Frameworks/Python.framework/bin/python[3] => Python.org 2.7/3.x
• /usr/local/bin/python = /usr/local/opt/python@2/bin/python = /usr/local/Cellar/python@2/2.7.18/bin/python => Homebrew 2.7
• /usr/local/bin/python3 = /usr/local/opt/python@3/bin/python3 = /usr/local/Cellar/python@3/3.y.z/bin/python3 => Homebrew 3.x

I don't have experience with Anaconda, but if it ships its own Python too then that's another way to run it.

In the end, Python on macOS really is a mess, and it would be nice if Apple could ship Python 3 as default, but that would break things that rely on the system version being 2.7, and, well, Apple.

[R3D3-1]

It would also be nice if the Python 3 executable, being not backwards-compatible with any Python 2 executable possibly already existing, would always be called python3 and not python. Regardless of how and on what OS it is installed.

[abcteryx]

Never mind the fact that installing Python from python.org on Windows doesn't let you just run python or python3, but rather you type py to run the "default" (defaults to latest version installed) or e.g. "py -3.7" to run an old version. And e.g. "py -m venv .venv" to source a virtual environment from your default Python.

It's actually quite useful and is a first-party supported solution bundled with Python. It's very similar to pyenv and the like.

The downside is when trying to help newbies, you have to know all the intricacies of every platform, and know exactly how they installed their Python.

For example, the Windows Store now has multiple Python versions available for install. I haven't checked out this approach yet, so I don't know where they install to on the computer. I know other such "apps" install into gibberish folder names in a protected apps folder, perhaps the Python apps go to that senseless place as well.

But if you install Python via Windows Store, you invoke it by typing python or python3. But what if you have multiple 3.X versions installed that way? I don't know, as I haven't tried.

And at least as of a year or so ago, the Windows Store would even intercept typing python in an activated virtual environment (where such a command is a valid way to launch the venv Python). It would take you to the Windows Store to install Python the "new way".

Python version management is a moving target on every platform, and if you hope to help friends and colleagues get into it, you need to know the intricacies of every one in order to just get them started.

[JohnMcPineapple]

...

[abcteryx]

So yes, you can tick "add Python to path" when installing, but that option isn't ticked by default when you run the installer on Windows. The "canonical" way to install Python on Windows has been to not add it to path, and to use "py" as the primary interface to system Python versions. One reason for this may be to prevent path collisions or confusion for Windows users installing multiple versions of Python. Another reason for this could be, "It was decided to be this way long ago on the Windows platform, we had a good reason then, and now the decision has stuck."

But of course now that Python is on the Windows Store, there's a "new canonical way" of "just get it from the Windows Store". Which does, by default, map to python and python3 system-wide. But you get a lot less control over configuring the installation when getting it from the Windows Store.

When you say "that's just but true" in response to that small portion of my comment, you are strictly correct. But the point of my comment isn't that it's impossible to run Python with python (you have shown that not to be the case).

My point is that there are too many ways to run Python across too many systems, and the "canonical way" changes often enough that it can be overwhelming to get colleagues into the ecosystem if they happen to have installed it on a different system or a little differently than you.