> They could have fixed most of this legacy code

They could have, but they didn't want to.

It's an open source project. Is there really much of a difference between "I'm not going to work on this system because it's terrible" and "I'm forking this system and I'm not going to support the previous version"?

In both cases you can say "well someone else will just come along and support it", and for py2 they did, for a bit. In fact I believe you can still pay if you happen to want py2 support.

But if you're not paying, you're saying "hey, this thing you work on and provide to me for free - why are you working on it in the way you want rather than the way I want??"

> In both cases you can say "well someone else will just come along and support it", and for py2 they did, for a bit

Was python-2 handed off to new maintainers? News to me.

> why are you working on it in the way you want rather than the way I want

Is "it" python-2 or python-3?

This isn't users demanding py3 devs support py2 - it's users asking that devs who no longer want to support py2 to hand it off to those that do, rather than blocking it.

When I say "the developers of X could have done Y better" I don't mean that they owe it to me in any way to have done so.

I'm just judging their technical decision making. They are perfectly entitled to delete the whole project and start a new one and I have absolutely no right to say they shouldn't.

But I do have a right to critique their decisions from a technical standpoint.

Yes it's interesting if this is cited as one of the motivations.

That's a problem of a language being oriented around a single implementation. Is it even defined by this implementation?

Compare to eg. C or C++.

Diversity, and interoperability is important as it is a significant contributor to longevity.

I do like that you've used the term "API" as I think that sums it up. To think of "Python" not as a language agreed by multiple implementors, the behaviour here is that of a "library" with an "API".

It would have taken considerable effort, regardless. This cost was offset onto the development teams in companies doing migrations. It was the decision made and if you don't like it, consider using another programming language. Perhaps consider that it's an open source project with a lot of contributors essentially working for free.

This explanation can be used to justify anyone breaking anything. You might as well argue no project ever needs to care about backwards compatibility.

How many downstream, Python dependent companies were funding its development? Everyone is entitled to their opinion. But if they build their system on a platform outside their control then they'll have to roll with the changes, fork it, or move to a different platform / fork.