5 ms·

> Migration path was unnecessarily difficult as was compatible code. I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of t

> Migration path was unnecessarily difficult as was compatible code. I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consisted of running 2to3, run tests with python3, and if anything breaked then just touch up the code to get it to work. I know it because I personally ported half a dozen projects throughout the years. I'll go as far as to claim that most problems porting old python code to 3 were either upstream dependencies dragging their feet or internal human/organizational issues. [1] https://docs.python.org/3/library/2to3.html https://docs.python.org/3/library/2to3.html

onphonenow 4y ago
This is totally false - code produced by 2to3 no longer ran on 2. So you ended up w a chicken and egg problem. Things like u would allow folks to keep compatibility with 2 while working in 3. Your comment is a perfect illustration of the issues. Lots of user blaming. No actual solution. As I said, it did start to get massively better at some point. Instead of condescending lectures on org issues they for example began allowing u”” in 3, which did not mess up Unicode handling in 3
- nulbyte 4y ago
  > This is totally false - code produced by 2to3 no longer ran on 2. I don't see where GP made a claim that it would. Why would one expect code written for a newer version, using features that don't exist in an older version, to run under the older version?
  - onphonenow 4y ago
    This was the issue. Why should a new version make it hard to run old code for no particular reason except to break things. Folks using u”” were already being careful with Unicode . Supposedly Unicode was important enough for 3 to default to it. The cost benefit of then destroying code using u”” made no sense to me. It was unnecessary. This was followed by the oh just upgrade thing. I’d love to see the “quick” upgrade guidos employer did. My guess is a total lie that it was easy and it probably took years and VC type money. It’s not about using new features, it’s about not unnecessarily breaking old or allowing for cross compatibility.
  - josefx 4y ago
    > using features that don't exist in an older version Except they broke the old way for existing features, required you to use the new way and in most cases you could manually write code so it would still work with both. Meanwhile the only tooling provided by the python 3 crowd screwed over anyone with an existing customer base stuck on python 2, which at least early on should have been a foreseeable problem. Not to forget that anyone stuck on python 2 was literally Satan and projects where outright "shamed" to drop python 2 support.
    - onphonenow 4y ago
      Given dependency chains the business case for these “quick” switches was often poor as well. Yes, Dropbox had $$ and guido - but that wasn’t everyone and most code was 2 at the time. Many folks would have been ok updating to 3 compatible approaches if it didn’t blow up their 2 story. That’s what ultimately happened in lots of cases when it became more doable. The rip and replace everything at once was a weird goal
  - qbasic_forever 4y ago
    If you published libraries on pypi you were in exactly that nightmare scenario. How do you support users on both versions of python (because let's be real, it took _ten years_ to change so you had to support both major versions) without two totally separate codebases and all the massive headaches that entails. There were some partial solutions like the library six and all kinds of related tricks to write python that was compatible with both 2 and 3 at the same time.
- simplotek 4y ago
  > This is totally false - code produced by 2to3 no longer ran on 2. That's what "breaking changes" and "backwards incompatible" means. What exactly is hard to grasp? > So you ended up w a chicken and egg problem. You really don't. Your code and your upstream dependencies need to be ported to python3. Once your dependencies are updated, all that's missing is you doing your job. Python2 has been on the path to deprecation for how long? A decade? You're fabricating problems where there are none. > Your comment is a perfect illustration of the issues. Lots of user blaming. There is no issue. When I had to port projects to Python3, I just ported them. No drama, no hangup. You're pretending there were problems where there were none, and you're throwing a tantrum when this fact is pointed out to you. There is really no justification for this. It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes. Some projects were rewritten from scratch in entirely different tech stacks in less time the likes of you complained they could not update their projects from python2 to python3.
  - onphonenow 4y ago
    “It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes.” What is it about python 3 that brings out this lecture stuff. I would really like to see the inside of this “easy” change at even the bigger most well resourced places. Google / Facebook / Dropbox etc. At small places where a program is working and programmer is gone they are not investing in ports. Anyways - they did eventually get a clue. It’s much easier NOW to handle this, but it wasn’t at the start. Yes, they did put u”” back in. No it did not destroy the world.
    - Izkata 4y ago
      > Yes, they did put u”” back in. No it did not destroy the world. This saga isn't completely over, over here: We still have code running python2 that we don't have the room to upgrade, and libraries that have to work with both python2 and python3. Meanwhile, people are pushing "code consistency" to the point where people outside our team are taking those libraries and running the "black" formatter on them - but "black" doesn't understand python2, so it removes the "u" prefix and breaks the library.
jeltz 4y ago
So why did for example Ruby not have such a painful transition from 1.8 to 1.9/2.0? My theory is that the Ruby people make the migration in many steps, it started even back in at least Ruby 1.8.6 and they did it with a lot of care on how to make the transition as painless as possible while the Python team just broke everything and bet on that tools like 2to3 would just magically solve it.
- onphonenow 4y ago
  Right. I think a key miss was underestimating value of code that would work w both 2 and 3. This avoids need to upgrade all at once. Relax things a tiny bit in 3, back port to 2 via futures, get a library like six going. It could have been a ton easier. In fairness by 3.5 maybe they’d realized this, but a lot of lecturing was done before. Initially recommendation was to upgrade all dependencies and programs to 3 and not try and make dependencies work w both
- JamesSwift 4y ago
  I think rubys TDD culture at the time also probably helped. My (purely unsupported) opinion is that the test suites were likely more fleshed out on ruby so its less of a risk to switch. That said, I still saw lots of 1.8.6 installs in the wild for quite some time after 2.0 hit.

onphonenow 4y ago

This is totally false - code produced by 2to3 no longer ran on 2. So you ended up w a chicken and egg problem. Things like u would allow folks to keep compatibility with 2 while working in 3. Your comment is a perfect illustration of the issues. Lots of user blaming. No actual solution. As I said, it did start to get massively better at some point. Instead of condescending lectures on org issues they for example began allowing u”” in 3, which did not mess up Unicode handling in 3

nulbyte 4y ago
> This is totally false - code produced by 2to3 no longer ran on 2. I don't see where GP made a claim that it would. Why would one expect code written for a newer version, using features that don't exist in an older version, to run under the older version?
- onphonenow 4y ago
  This was the issue. Why should a new version make it hard to run old code for no particular reason except to break things. Folks using u”” were already being careful with Unicode . Supposedly Unicode was important enough for 3 to default to it. The cost benefit of then destroying code using u”” made no sense to me. It was unnecessary. This was followed by the oh just upgrade thing. I’d love to see the “quick” upgrade guidos employer did. My guess is a total lie that it was easy and it probably took years and VC type money. It’s not about using new features, it’s about not unnecessarily breaking old or allowing for cross compatibility.
- josefx 4y ago
  > using features that don't exist in an older version Except they broke the old way for existing features, required you to use the new way and in most cases you could manually write code so it would still work with both. Meanwhile the only tooling provided by the python 3 crowd screwed over anyone with an existing customer base stuck on python 2, which at least early on should have been a foreseeable problem. Not to forget that anyone stuck on python 2 was literally Satan and projects where outright "shamed" to drop python 2 support.
  - onphonenow 4y ago
    Given dependency chains the business case for these “quick” switches was often poor as well. Yes, Dropbox had $$ and guido - but that wasn’t everyone and most code was 2 at the time. Many folks would have been ok updating to 3 compatible approaches if it didn’t blow up their 2 story. That’s what ultimately happened in lots of cases when it became more doable. The rip and replace everything at once was a weird goal
- qbasic_forever 4y ago
  If you published libraries on pypi you were in exactly that nightmare scenario. How do you support users on both versions of python (because let's be real, it took _ten years_ to change so you had to support both major versions) without two totally separate codebases and all the massive headaches that entails. There were some partial solutions like the library six and all kinds of related tricks to write python that was compatible with both 2 and 3 at the same time.
simplotek 4y ago
> This is totally false - code produced by 2to3 no longer ran on 2. That's what "breaking changes" and "backwards incompatible" means. What exactly is hard to grasp? > So you ended up w a chicken and egg problem. You really don't. Your code and your upstream dependencies need to be ported to python3. Once your dependencies are updated, all that's missing is you doing your job. Python2 has been on the path to deprecation for how long? A decade? You're fabricating problems where there are none. > Your comment is a perfect illustration of the issues. Lots of user blaming. There is no issue. When I had to port projects to Python3, I just ported them. No drama, no hangup. You're pretending there were problems where there were none, and you're throwing a tantrum when this fact is pointed out to you. There is really no justification for this. It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes. Some projects were rewritten from scratch in entirely different tech stacks in less time the likes of you complained they could not update their projects from python2 to python3.
- onphonenow 4y ago
  “It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes.” What is it about python 3 that brings out this lecture stuff. I would really like to see the inside of this “easy” change at even the bigger most well resourced places. Google / Facebook / Dropbox etc. At small places where a program is working and programmer is gone they are not investing in ports. Anyways - they did eventually get a clue. It’s much easier NOW to handle this, but it wasn’t at the start. Yes, they did put u”” back in. No it did not destroy the world.
  - Izkata 4y ago
    > Yes, they did put u”” back in. No it did not destroy the world. This saga isn't completely over, over here: We still have code running python2 that we don't have the room to upgrade, and libraries that have to work with both python2 and python3. Meanwhile, people are pushing "code consistency" to the point where people outside our team are taking those libraries and running the "black" formatter on them - but "black" doesn't understand python2, so it removes the "u" prefix and breaks the library.

jeltz 4y ago

So why did for example Ruby not have such a painful transition from 1.8 to 1.9/2.0? My theory is that the Ruby people make the migration in many steps, it started even back in at least Ruby 1.8.6 and they did it with a lot of care on how to make the transition as painless as possible while the Python team just broke everything and bet on that tools like 2to3 would just magically solve it.

onphonenow 4y ago
Right. I think a key miss was underestimating value of code that would work w both 2 and 3. This avoids need to upgrade all at once. Relax things a tiny bit in 3, back port to 2 via futures, get a library like six going. It could have been a ton easier. In fairness by 3.5 maybe they’d realized this, but a lot of lecturing was done before. Initially recommendation was to upgrade all dependencies and programs to 3 and not try and make dependencies work w both
JamesSwift 4y ago
I think rubys TDD culture at the time also probably helped. My (purely unsupported) opinion is that the test suites were likely more fleshed out on ruby so its less of a risk to switch. That said, I still saw lots of 1.8.6 installs in the wild for quite some time after 2.0 hit.