Python has no standard and the language implemented by the reference compiler is a moving target. (E.g. every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2.). The ecosystem in general is similarly dynamic. It's common to install a set of specific versioned packages and Python interpreter to get a package running.
It's not really a language where you can write something and be confident it'll still work in ten years with the latest release of Python that'll be shipping with distros.
> every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2
People had 15 years to move from 2 to 3.
I had to port dodo files from 2 to 3, it's a 10 minutes job. Most of the time, running 2to3 on it does the job automatically.
After all, you only use the stlib for task runners, delegating a lot of work to bash, and they are quite short.
> It's not really a language where you can write something and be confident it'll still work in ten years
I still have Python 2.7 projects running fine, and reinstalled one serving half million users a few month ago.
But even without this, Python was created in 1991, and Python 3 was released in 2008, that's 17 years between first release and the first big migration. To compare, go is 14 years old. In total.
Plus your build file will have been edited so many times by the end 10 years anyway.
Make has a lot going for it, but this is a terrible argument.
And yet, almost every random python script I come across does not work on my system, either because of modules or installation layout differences between the authors system and mine, or the passage of a mere few months or a year of time.
They are usually fixable of course. Assuming the thing worked on the authors system at all, it's possible to diagnose and fix it up for the current environment. But that has to be done, and sometimes takes more than a few minutes to hunt everything down.
And then one day I started seeing these pyc directories appearing out of the blue, right in whatever directory any script happened to be in. The same scripts that didn't do that yesterday. What an awesome thoughtfully engineered system!
The argument was not terrible, it was plain lived experience fact.
I don’t disagree with you, but I also don’t think that’s a bad thing. Things certainly don’t break quickly, there are years of warnings for deprecated functionality. I also think it’s not a bad thing to drop old functionality. It may not be warranted that code that worked 10/20 years ago should still work today. Languages evolve, and by pruning old features, footguns, or bad patterns, the language can evolve without carrying the weight of every mistake or legacy feature.
