Hacker News Reader

Comment by copx | Hacker News Reader

>The 2.X => 3.X transition really appears to have been bungled here, which is a shame.

Obviously, the question is what went wrong.

Personally I think the dev team gave users too much time to switch.

The Python devs should have only given users one or two years to upgrade. Making it clear that all support for Python 2 would end after that period.

Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile.

They made this worse by backporting features from Python 3 to Python 2, something they should have never done. Python 2 should not have gotten any new features after the release of Python 3.

Python 3 advocates like to blame the users for not upgrading, but I think that is / was simply the result of the actions of the dev team which made staying with Python 2 too comfortable and moving to Python 3 not attractive enough.

View on HN

> Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile.

This is the core issue, but you're putting cart before horse a bit: if there's not much to gain from switching, why would any reasonable person switch? And, most importantly, why is it a problem that needs solving at all?

Exactly.

For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine.

The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.

AFAIR the messy release for ruby was 1.8 -> 1.9 (the new VM, changes to encodings, OS-level threading etc) but both that change and 1.9->2.0 worked out _much_ better than python 2->3.

As I understand it, Matz considers the upgrade strategy until now quite successful, mostly because at the same time breaking changes occurred people got things they wanted (e.g. faster VM) which encouraged them to upgrade.

Hence the "ruby 3 will be 3 times faster than ruby 2" idea, that's the carrot that should contrast people's will to not update.

I suspect that Ruby also benefited from having a comparatively young community. There are folks that used Ruby before Rails, but the majority of Rubyists only started in 2006 or later, so they are used to the faster replacement rate of modern Open Source and didn't have so many legacy codebases to worry about.

Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile.

Not only that, they effectively took away a lot of vital shiny old things like numpy and django. It was something like 3 years between python 3.0 and the first stable releases of numpy and django with python support. That was 3 years where python 3 was effectively useless to a large number of python developers, and you can lose a lot of momentum in 3 years. Had the core python team gotten together with the teams for numpy, scipy, django and a couple of other big name libraries and coordinated the release of python 3 with versions of all those libraries that would work with python 3, then I imagine things might have gone a lot smoother.

No, the problem is that Python 3 sucked, and still sucks.

Twisting your user's arms even more painfully won't solve the problem, it will just accelerate users switching away to other languages or forks.

There's plenty of problems with Python 3 and the transition, none of them are that "Python 3 sucks".

You know that, of course, otherwise you'd have provided an actual claim rather than a generic complaint.

How does python 3 suck? It seems quite pleasant to use for me, and I much prefer the clean bytes/str separation.

Reply on news.ycombinator.com