3 ms·

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 yo

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.

j88439h84 7y ago
Six was available for years (2011) before Mercurial even started porting (2015). https://github.com/benjaminp/six/graphs/contributors https://github.com/benjaminp/six/graphs/contributors
- eesmith 7y ago
  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.)
choppaface 7y ago
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.
- Jasper_ 7y ago
  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++.
  - choppaface 7y ago
    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 ...
    - Jasper_ 7y ago
      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.
      - choppaface 7y ago
        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.
        richardwhiuk 7y ago
        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.

j88439h84 7y ago

Six was available for years (2011) before Mercurial even started porting (2015). https://github.com/benjaminp/six/graphs/contributors https://github.com/benjaminp/six/graphs/contributors

eesmith 7y ago
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.)

choppaface 7y ago

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.

Jasper_ 7y ago
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++.
- choppaface 7y ago
  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 ...
  - Jasper_ 7y ago
    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.
    - choppaface 7y ago
      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.
      - richardwhiuk 7y ago
        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.