[brodie]

The Python core devs did not have the time or motivation to support the old codepaths in the CPython runtime, and the legacy code was getting in the way of a lot of longtime wants and needs for improving performance, runtime maintainability, language ergonomics, and the standard library. They also specifically increased the major revision number to signal their intent to move on from that legacy.

But you kind of addressed your entire spiel: Hindsight is exceedingly easy. They didn't realize how inadequate their migration tooling was, or how very entrenched Python 2 is in various places. It's hard when you don't know what you don't know and you're highly motivated by hopeful aspirations.

[logicchains]

>The Python core devs did not have the time or motivation to support the old codepaths in the CPython runtime, and the legacy code was getting in the way of a lot of longtime wants and needs for improving performance, runtime maintainability, language ergonomics, and the standard library.

They could have fixed most of this legacy code without changing the external user-facing API so much.

[lexicality]

> 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??"

[Chris2048]

> 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.

[tsimionescu]

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.

[zbuf]

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".

[sgt]

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.

[unishark]

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

[paulryanrogers]

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.

[willis936]

I don’t think hindsight can be claimed here. It was a decision that was not made from ignorance. The Python developers chose to sacrifice backwards compatibility. Other languages do not typically make such choices and if they do they make updating codebases relatively easy.

Nothing about python versioning is easy. It’s a disaster and the key reason I do not start any projects in python.

[Blikkentrekker]

> The Python developers chose to sacrifice backwards compatibility.

And it is quite clear that that choice was not based on accurate estimates and insights.

The original e.o.l. was laughably short and then had to be doubled. It was quite clear they based their choice on the assumption that consumers would have all switched to e at a time when 2 was still used by 80%.

They made that choice based on what can only be seen as complete ignorance of the cost of rewriting software.

Right now, the biggest reason to drop Python 2 for most serious consumers is not any of the improvements that Python 3 brings, but that it is e.o.l..

[ZuLuuuuuu]

> Other languages do not typically make such choices and if they do they make updating codebases relatively easy.

I want to understand what was so hard about porting code from Python 2 to 3. I ported a few tens of thousand lines of Python 2 code to Python 3 and it was pretty trivial. In my experience the only thing that made porting code hard was when a package you depended on was not ported to Python 3 yet. But maybe my experience does not reflect some other cases. Can you eloborate on what was so hard about porting code from Python 2 to 3?

[willis936]

I have a pretty nasty example here:

https://news.ycombinator.com/item?id=25890126

How do I regression test five different pieces of DAQ hardware? My best plan is to pull them working systems and deal with them missing. I don’t think it’s a good use of resources to buy extra DAQ cards just for a regression test bed.

Regardless of that, moving from python 2.5 to 2.7 is not trivial because not all used libraries were even updated to 2.7 from 2.5. Some that were broke backwards compatibility. How far do I have to bend backward just to get in the right place to update to python 3? I see many comments trivializing the effort needed to update to python 3 because they know of narrow use cases and expect large amounts of resources to maintain code. That isn’t the reality for most users.

[OakNinja]

The hardship of porting from 2 to 3 very much depends on how critical the software is. Porting 1000 lines of python 2 that deals with files encoded in various ways where it’s impossible to test all edge cases and where a failure might lead to huge liability charges is hard not because it’s hard to run 2to3 and do some random tests, but because you don’t know what you have missed. And still, a 300k lines of code project might be fine to just run 2to3 on and then find the bugs as you go. It’s a matter of context.

[wegs]

And the opposite -- tons of little unimportant scripts sitting around that add a lot of value as a whole, but just aren't worth devoting to rewriting on a whim of poor decision making skills of the Python developer team....

I have Python code dating back to when I was an undergrad. It's sad to see the Python team decide to nuke that. My C code from then (mostly) runs fine still.

The team decided to externalize a massive cost on its community without much benefit. That was sad to see at the time, and it continue to be sad to see.

[labawi]

As someone who does a decent part of development in python, I'd say you are using the wrong language, if you can't test your edge cases and have huge liabilities.

Python code is inherently almost-untestable and fragile. These days, when coding something critical and non-trivial, I choose a memory-safe language with static typing and type inference, ADTs, pattern matching and try to write simple yet pure functional code with well defined semantics, that works almost by definition.

[carapace]

Sure, but how does that help? I mean, absent a time machine, you're technically correct but operationally moot.

[labawi]

If you have a liability situation, maybe you could work to rectify it, instead of blaming 2to3 transition that's shaking up your house of cards?

[Blikkentrekker]

These are exactly the concerns of serious enterprises that the Python developers have missed, that made them seem as though they be hobbyists that have never dealt software that actually powers infrastructure.

[paulryanrogers]

Python was intended for education originally. It's possible that some uses are just too far outside that wheelhouse to expect it to work well forever. Doubtful I'll ever write desktop GUIs in PHP for example, though it appears some have already done it.

[Blikkentrekker]

The standard library of 2 already came with many facilities that go well beyond that.

They targeted business; it came to be adopted by business; and then they were surprised that business was not enthusiastic about updating currently working code with all the potential regressions and downtime that might come from it.

[eesmith]

Could you explain how "Python was intended for education originally."?

As I recall, Python was designed for the Amoeba operating system, and drew on experience from implementing ABC; ABC was definitely designed for education.

But ABC != Python. Checking now, the first Usenet post for Python 0.9 says:

> Python can be used instead of shell, Awk or Perl scripts, to write prototypes of real applications, or as an extension language of large systems, you name it.

See https://groups.google.com/g/comp.sys.sgi/c/7r8kVgQ84j0 .

It doesn't specifically mention using Python for education.

[ZuLuuuuuu]

There are certainly some cases where even the smallest backward incompatible change would cause serious problems on some systems. Thanks for giving an example, instead of just downvoting.

[lmm]

The problem was that you could only port once all the libraries you use had ported, but libraries didn't want to commit to abandoning Python 2 quickly.

[ZuLuuuuuu]

Agreed, that was also my experience as well, the hardest part was not changing our codebase but if we depended on a package that was not ported to Python 3 yet.

[Chris2048]

> The Python core devs did not have the time or motivation to support the old codepaths

Then sounds like they didn't want to be python devs anymore, good luck on their new project..

Instead they held onto the reins and drove python into the ground so that their new code could devour the remains of the old.

> They didn't realize how inadequate their migration tooling was

A shame then that they decided that migration was mandatory. They don't need to know either, they just have to encourage users to migrate, rather than force them to. Saying "They didn't realize ... how very entrenched Python 2 is" is basically saying "we didn't think we'd encounter (significant) resistance". Their "hopeful aspirations" was that everybody (that mattered) would be onboard, which is why they didn't bother ask..