Hacker News Reader

Comment by michaelhoffman | Hacker News Reader

The biggest problem with the Python 2 to Python 3 transition was not that breaking changes were made. It’s that breaking changes were made in a way such that you could not easily have code that worked both on Python 2 and Python 3.

It took years before the advent of six, Python 3 u’’ literals, and modernize. The author discusses this at length.

View on HN

Another big problem is there was no significant incentive to adopt Python 3. That’s why it took so long for large projects to transition. In comparison, during the last decade, C++ went from dodgy C++11 toy projects to all new code being written in modern C++. The modern feature set is that good.

C++ doesn't mandate you switch from std::cout to fmt in order to use lambdas. If they did that, I think we'd see a lot less modern C++.

That’s a find-and-replace fix that can be addressed reliably. A relatively smaller problem versus moving off of boost.

The compiler support for C++11 (and especially inconsistencies in Debian packages, compiled flags, etc) was a very painful issue for several years. But auto is that useful ...

Right, moving to std::cout to fmt could be as simple as a find-and-replace fix. That the C++ committee could have inflicted this minimal pain on their users, but chose not to do it, shows some amount of concern for backwards compatibility and old codebases. By comparison, Python 3 changed the entire text model and dropped the mic, and waited for 8 years to start to pick the pieces back up.

I guess I don’t understand your argument that “Python 3 changed the entire text model and dropped the mic.” format strings are optional; the old % operator still works fine. The change to unicode is dramatic, but personally I haven’t run into major problems. I’ve had unit tests break because of it, but that’s why one has unit tests. I’ve also worked on a very large python webapp that underwent painful internationalization, and in that case we ended up using unicode strings everywhere anyways.

The % didn't use to work fine. .iteritems() was made for no good reason.

Python 3 could have required all strings began with u" or b", but they didn't - they did something which encouraged breakage.

Six was available for years (2011) before Mercurial even started porting (2015).

https://github.com/benjaminp/six/graphs/contributors

That was part of the "discusses this at length". Part of the relevant discussion is:

> So I'm not sure six would have saved enough effort to justify the baggage of integrating a 3rd party package into Mercurial. (When Mercurial accepts a 3rd party package, downstream packagers like Debian get all hot and bothered and end up making questionable patches to our source code. So we prefer to minimize the surface area for problems by minimizing dependencies on 3rd party packages.)

Reply on news.ycombinator.com