Arch Linux drops Python 2

Python 2 has been end of life for over two years (since 2020-01-01), and deprecated for much longer. At a certain point, IMHO it becomes acceptable (for distros, libraries, upstreams, etc.) to say "if you're still on Python 2, then compatibility is your problem. We won't support it anymore, nor will we go out of our way to make life easy for you." As early as 2011, they wrote PEP 404 explicitly spelling out that "[t]he official upgrade path from Python 2.7 is to Python 3." It's not as if people haven't had adequate warning that something like this was eventually going to happen.

> One could argue that "just use the same environment as back then", and engineers generally would prefer that, but that is often not possible because the commercial EDA tool vendors need lots of convincing to hand out licenses to tools that old so one is often forced to new tools and environments. EDA vendors typically realise the problem and tend to have quite good backwards compatibility in their tools, but that doesn't solve the script issue.

That assumes the vendor CAN hand out a licence ...

I've just seen on one of my mailing lists, a request for UniData 5 point something install media. I don't know how old that is, but the current vendor (Rocket) doesn't have a copy. They've taken over most of the Pick vendors, and in the process a lot of history has probably been lost. Trying to get hold of commercial products from that long ago is probably very difficult simply to find an extant copy!

Cheers,
Wol

"You write as someone who has never seen a large scale real world deployments" Nice start to a reasoned response.

My nascent Civil Engineering career morphed into IT around 30 odd years back. You will have heard of some of my little firm's customers - strange but likely true.

I own a treasured screwdriver with a wooden handle and a simple flat blade - you may do too. It still works - mine was my great granddad's and was made in the 1880s or so. The handle has many years of skin oils and various other oils and who knows what else infused into it and it has a phenomenal patina which has perfectly preserved it. The metal bit is a masterpiece of forging and heat treatment. The whole thing is chromium infused steel for rust resistance. The shaft is roughly like modern mild steel - it is slightly ductile, which means it deals well with torsion. The blade part has been heat treated in two parts. The whole "blade" has been hardened a bit and the leading edge has been hardened more. The part that you stick in a flat edge screw is as good today as it was 140 odd years back.

I also have my dad's ratchet screwdriver. This one has a wooden handle too and is only 60 odd years old. It works fine too and just needs a light oil every few years or so.

I have several electric drill drivers, one of which you have to ensure you get a leg in the way to avoid wrenching your wrist and a wide set of modern cross head/flat head/insulated screwdrivers and all the rest.

Guess which set of tools I use these days? I maintain the old ones and they still work but a De Walt wrist destroyer with a decent bit is my go to screwdriver.

The above is simply a fun digression but I'm sure we can whistle up an analogy. I think you are missing multiple points:

1. "Entitlement" - Python devs should do what I want them to for my use case.
2. "Laziness" - I can't be bothered to maintain my stuff.
3. "Inertia" - Its always done like this and I want it to last forever.
4. "Lack of imagination" - We can't be arsed with change.

You can always grab a Python2 and maintain it yourself if your code is that important. It's a simple cost/benefit analysis.

Whilst we are at it, we should note that this article is about Arch dumping Python2 not Centos or whatevs it is is called today. I run Arch on my personal laptop and work desktop - I doubt you do on your work gear and so the whole argument is rather moot. I do suggest you plan ahead though.

Interesting. I never used py.exe. That can be handy, but it would not have helped in my case. We were using Python in our CI and the assumption was: since we start the script from Git Bash, the shebang is going to work properly, because Bash knows about shebangs. And indeed it does, but we still could not write "#!/usr/bin/env python3" because there was no python3.exe file (until we created one by copying python.exe to python3.exe, meh).

I still believe being able to reliably depend on the availability of a python3 binary on all supported platforms would have helped a lot.