Hacker News Reader

Comment by ceronman | Hacker News Reader

What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding.

I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python3/

View on HN

Could someone provide a summary of the kinds of mistakes/remedies?

Did not watch the presentation but IMO the primary mistake was not declaring EOL for 2.x sooner. Other languages had similarly breaking changes and they simply gave short time before legacy version was declared EOL and developers ported their applications to the new version.

In Python it took 10 years, and even now you can't get companies to migrate, because why make developers do the work when application still can be used. Many places will probably start the migration in 2020, which shows that giving 10 years head start was a mistake and all it did was create FUD and division in the community.

The Python 3 immediately picked up for new projects after announcement that 2.7 will no longer have new feature and only bugfixes in 2015. Industry will wait for the last moment when all support for 2.7 will be ceased in 2020.

For the record, Python 2.7 EOL was originally 2015. In 2014, it was moved later, likely because RedHat would continue to maintain it for free anyway.

https://legacy.python.org/dev/peps/pep-0373/#id2

One mistake was providing 2to3 as a migration path. This required projects to move completely from 2 to 3, for libraries it meant that they had to either stop supporting 2 (which were the majority of their users) or forking and maintaining both versions. The remedy was to make it possible for libraries to be both 2.7 and 3.x compatible, using tools such as six.py and making some changes to 3.x to make it more compatible with 2 (e.g. adding u'' strings).

The problem with six is that once you decide to use it your entire code base must be written with the lowest common denominator in mind, in this case py2.7. You can't use six.py at the interface boundaries and nice python3 features inside your implementation. Six is only useful for old 2.7 libraries that want to quickly be 3.x compatible and still maintain their 2.7 compatibility, not if you have an old 2.7 application and want to incrementally add 3.x features.

The proper way make a major breaking change like python did is to provide a bridge between the two versions, so you could import 2.7 modules from 3.x applications, and even the other way around. As of today there is still no such thing.

The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.

Those three scripting languages actually an interesting comparison.

Perl 5 -> 6 broke all your code in exchange for a whole new language. Some people moved to Perl 6, some to other languages, and a lot stayed with Perl (5), which still runs programs written in Perl 1.

Ruby 1.8 -> 1.9 broke most of your code in exchange for minor cleanups. But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along.

Python 2 -> 3 also broke most of your code in exchange for minor cleanups. Users expected some stability, but the language's culture demanded conformity. The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3.

> But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along.

The main reason people switched probably wasn't rails making people expect breakage, the main reason was that (a) it was relatively easy to rewrite your code to work on both 1.8 and 1.9 (as long as your dependencies had already done it), and (b) 1.9 was much faster.

> The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3.

I think that's the most succinct way to put this whole debacle I've ever seen. I'm totally stealing this.

I do not think double standard means what you think it means.

Ruby had 1.9. It was like the Python 3 situation in miniature, and Matz has said he’s keen to avoid such a mistake again.

It also was in a minor version change 1.8 -> 1.9, but people moved on because 1.8 was declared EOL this is what Python was missing. Python 3 is 10 years old and 2.7 is still supported (bufixes, but still).

If you look at timing, Python 3 picked up for new projects in 2015, when PSF declared that no new features will be backported to Python 2 from 3.

I believe the industry will wait for 2020 to start migrating existing code after Python 2.7 will be declared EOL.

That massive chip on your shoulder is weighing you down.

If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare.

There might be some good lessons there.

Ruby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python.

People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded

“Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.

Reply on news.ycombinator.com