6 ms·

2to3 really showed that Python didn't understand their audience. If they had started a new project called COBRA and just eventually had it over take python the

2to3 really showed that Python didn't understand their audience. If they had started a new project called COBRA and just eventually had it over take python the world would be all over it. But massive breaking changes going from 2 to 3 was a disaster for their audience. Worse still you could hear the acrimony in Pythons communications on the topic.

groestl 4y ago
I'm wondering, is there work on how python 3's changes could have been promoted in smoother way?
- EdwardDiego 4y ago
  An excellent question, how do you smoothly break compatibility?
  - tormeh 4y ago
    Really annoying deprecation notices help a bit.
  - broeng 4y ago
    I think two aspects have played a significant part in the migration pain: 1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable. 2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI. Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
    - peterfirefly 4y ago
      They also changed the C interface at the same time -- and many Python libraries had non-trivial amounts of C code in them because Python was and is so slow. It was also for a time impossible (or close to impossible) to run the same Python code in 2.x and 3.x. It helped when later 2.x versions acquired more 'from __future__ import'. They really aimed for making it maximally hard to support v2 and v3 at the same time which created a nasty coordination problem: why upgrade if the libraries aren't ready and why upgrade the libraries if there are no users.
  - flohofwoe 4y ago
    Easy: Introduce breaking new version, but freeze and continue to support old versions (e.g. a python3 install should include the ability to fallback to python2). A real world example of this philosophy are the D3D APIs. Each new major D3D version had a completely new API, but old D3D versions are supported forever. Python source files then somehow need to announce what python runtime version they expect. Having to support old versions forever also should make the maintainers think twice before breaking compatibility again.
    - psychphysic 4y ago
      Very interesting comparison to D3D. The one of the things Microsoft appear to have mastery of is making sure users and devs don't feel breaking changes. Drivers generally as well as D3D.
  - ilyt 4y ago
    Feature flags or at worse, transpile. Perl did the first (in form of just writing what version features you want to use in header) and they also went thru "UTF8ication" of the language. Even if you don't get all old code to work, having say 80% of it working means to start using Py3 you'd need to only initally rewrite 20% of the codebase, run tests and off you go, then migrate rest slowly over time.
  - deleted 4y ago
    [deleted]
  - JamesSwift 4y ago
    Angular2 is a model for breaking changes IMO. The naming convention is a travesty, but the upgrade process was really elegant. The biggest bits: - Added some stuff to AngularJS to make it more Angular2 compatible so that you could get closer to the target without taking in the breaking changes - A thing called ngUpgrade let you dual-boot AngularJS and Angular2 together, so that you could transition parts of your program over time without needing to redo the whole thing - Well documented migration guides for each step, outlining what you need to do in order to move from X version to Y version.
    - Izkata 4y ago
      I've never used any version of Angular, but from what I've seen people complain about it was also a huge breaking change - so much of peoples' apps had to be rewritten they ended up just switching to React or Vue or something.
      - JamesSwift 4y ago
        Fundamentally yes it was a huge shift. Practically, no, you dont need to rewrite a bunch _if_ you followed the upgrade path laid out as I described in my original post. They backported a lot of stuff so that you could do the rewrite incrementally.
  - nlitened 4y ago
    Just don't break it. Problem solved.
Stranger43 4y ago
You mean the way rakudo took over the entire perl ecosystem when it finally arrived? I suspect a lot of the controversial decusions made doing the 2to3 migration by the python foundation was deliberately designed to avoid a situation similar to what happened to perl when the time came to cleanup some of the old cruft from the language.
- xdennis 4y ago
  The difference is that Perl 6/Raku was a huge change from Perl 5. For Python, the small improvements weren't worth the break in compatibility.
  - Conan_Kudo 4y ago
    You underestimate how big of a change Python 3 actually was. Changing how strings and bytes are handled has a huge blast radius. It broke almost every library or application I worked on. Everything else was peanuts to that semantic change. It was a necessary change too. Supporting Unicode strings or mixed-encoded strings was absolutely awful in Python 2 and almost not worth doing. Python 3 made that work properly. Arguably, the only real mistake was using UTF-16 instead of UTF-8 for strings. But back then, nobody knew what would take off and Windows natively uses UTF-16, so...
    - sigzero 4y ago
      Python 2 to 3 wasn't even close to the change of Perl 5 to 6 (later Raku). Sorry, it just isn't even a comparison.
    - mort96 4y ago
      Python 3 had a HUGE impact on existing code, yes. Everything broke. But Python 3 didn't actually change much for the people writing new Python code, it just broke the old code. Raku is a completely different language from Perl. Writing Raku instead of Perl 5 is like writing Rust instead of C++.
hansonkd 4y ago
Well, trying to sell a project to the higher-ups is a lot easier when you can say > Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3" Then the execs say "we are on 2?? and there is a 3??! what are we waiting for?!" A whole lot easier than trying to say: > Hey, there is a new interpreter out there called COBRA. We need to rewrite our whole codebase to use it, there isn't a tremendous amount of benefit, but its the new thing from the same people and eventually everyone will use it. Trust me. To which the execs ask you to stop fooling around and get back to work.
- psychphysic 4y ago
  It's simple. Python doesn't exist anymore, everyone's using COBRA. We can dedicate a dozen engineer months to switch to COBRA. Or thousands to maintain python ourselves...
- TylerE 4y ago
  Meanwhile, in the real world, the feature backlog means that 2 to 3 never happened for a lot of us.
  - hansonkd 4y ago
    It was a pretty easy sell for us because Django ended Python 2 support in 1.11 So in reality the conversation actually went more like "hey you know the web framework we use for all of our services. yeah, that will be stuck at the same version for forever with no security releases and unable to use any new integrations unless you devote 2 engineers for 3 months and take the medicine now instead of digger a deeper hole" But it was a lot easier for the CEO to digest `2 -> 3` as a clear path to the future as opposed to switching to a new language.
    - TylerE 4y ago
      Much harder.for us as our code base predates Django so we (years before I was hired) have our own framework, our own orm, … so we’d basically have to port everything all at once, with no clue if we other half is correct until you’ve ported both.

groestl 4y ago

I'm wondering, is there work on how python 3's changes could have been promoted in smoother way?

EdwardDiego 4y ago
An excellent question, how do you smoothly break compatibility?
- tormeh 4y ago
  Really annoying deprecation notices help a bit.
- broeng 4y ago
  I think two aspects have played a significant part in the migration pain: 1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable. 2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI. Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
  - peterfirefly 4y ago
    They also changed the C interface at the same time -- and many Python libraries had non-trivial amounts of C code in them because Python was and is so slow. It was also for a time impossible (or close to impossible) to run the same Python code in 2.x and 3.x. It helped when later 2.x versions acquired more 'from __future__ import'. They really aimed for making it maximally hard to support v2 and v3 at the same time which created a nasty coordination problem: why upgrade if the libraries aren't ready and why upgrade the libraries if there are no users.
- flohofwoe 4y ago
  Easy: Introduce breaking new version, but freeze and continue to support old versions (e.g. a python3 install should include the ability to fallback to python2). A real world example of this philosophy are the D3D APIs. Each new major D3D version had a completely new API, but old D3D versions are supported forever. Python source files then somehow need to announce what python runtime version they expect. Having to support old versions forever also should make the maintainers think twice before breaking compatibility again.
  - psychphysic 4y ago
    Very interesting comparison to D3D. The one of the things Microsoft appear to have mastery of is making sure users and devs don't feel breaking changes. Drivers generally as well as D3D.
- ilyt 4y ago
  Feature flags or at worse, transpile. Perl did the first (in form of just writing what version features you want to use in header) and they also went thru "UTF8ication" of the language. Even if you don't get all old code to work, having say 80% of it working means to start using Py3 you'd need to only initally rewrite 20% of the codebase, run tests and off you go, then migrate rest slowly over time.
- deleted 4y ago
  [deleted]
- JamesSwift 4y ago
  Angular2 is a model for breaking changes IMO. The naming convention is a travesty, but the upgrade process was really elegant. The biggest bits: - Added some stuff to AngularJS to make it more Angular2 compatible so that you could get closer to the target without taking in the breaking changes - A thing called ngUpgrade let you dual-boot AngularJS and Angular2 together, so that you could transition parts of your program over time without needing to redo the whole thing - Well documented migration guides for each step, outlining what you need to do in order to move from X version to Y version.
  - Izkata 4y ago
    I've never used any version of Angular, but from what I've seen people complain about it was also a huge breaking change - so much of peoples' apps had to be rewritten they ended up just switching to React or Vue or something.
    - JamesSwift 4y ago
      Fundamentally yes it was a huge shift. Practically, no, you dont need to rewrite a bunch _if_ you followed the upgrade path laid out as I described in my original post. They backported a lot of stuff so that you could do the rewrite incrementally.
- nlitened 4y ago
  Just don't break it. Problem solved.

Stranger43 4y ago

You mean the way rakudo took over the entire perl ecosystem when it finally arrived? I suspect a lot of the controversial decusions made doing the 2to3 migration by the python foundation was deliberately designed to avoid a situation similar to what happened to perl when the time came to cleanup some of the old cruft from the language.

xdennis 4y ago
The difference is that Perl 6/Raku was a huge change from Perl 5. For Python, the small improvements weren't worth the break in compatibility.
- Conan_Kudo 4y ago
  You underestimate how big of a change Python 3 actually was. Changing how strings and bytes are handled has a huge blast radius. It broke almost every library or application I worked on. Everything else was peanuts to that semantic change. It was a necessary change too. Supporting Unicode strings or mixed-encoded strings was absolutely awful in Python 2 and almost not worth doing. Python 3 made that work properly. Arguably, the only real mistake was using UTF-16 instead of UTF-8 for strings. But back then, nobody knew what would take off and Windows natively uses UTF-16, so...
  - sigzero 4y ago
    Python 2 to 3 wasn't even close to the change of Perl 5 to 6 (later Raku). Sorry, it just isn't even a comparison.
  - mort96 4y ago
    Python 3 had a HUGE impact on existing code, yes. Everything broke. But Python 3 didn't actually change much for the people writing new Python code, it just broke the old code. Raku is a completely different language from Perl. Writing Raku instead of Perl 5 is like writing Rust instead of C++.

hansonkd 4y ago

Well, trying to sell a project to the higher-ups is a lot easier when you can say > Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3" Then the execs say "we are on 2?? and there is a 3??! what are we waiting for?!" A whole lot easier than trying to say: > Hey, there is a new interpreter out there called COBRA. We need to rewrite our whole codebase to use it, there isn't a tremendous amount of benefit, but its the new thing from the same people and eventually everyone will use it. Trust me. To which the execs ask you to stop fooling around and get back to work.

psychphysic 4y ago
It's simple. Python doesn't exist anymore, everyone's using COBRA. We can dedicate a dozen engineer months to switch to COBRA. Or thousands to maintain python ourselves...
TylerE 4y ago
Meanwhile, in the real world, the feature backlog means that 2 to 3 never happened for a lot of us.
- hansonkd 4y ago
  It was a pretty easy sell for us because Django ended Python 2 support in 1.11 So in reality the conversation actually went more like "hey you know the web framework we use for all of our services. yeah, that will be stuck at the same version for forever with no security releases and unable to use any new integrations unless you devote 2 engineers for 3 months and take the medicine now instead of digger a deeper hole" But it was a lot easier for the CEO to digest `2 -> 3` as a clear path to the future as opposed to switching to a new language.
  - TylerE 4y ago
    Much harder.for us as our code base predates Django so we (years before I was hired) have our own framework, our own orm, … so we’d basically have to port everything all at once, with no clue if we other half is correct until you’ve ported both.