3 ms·

I don't think migration was given enough serious consideration until Python 3.3 in 2012, and even then there were some baffling and massively unnecessarily migr

I don't think migration was given enough serious consideration until Python 3.3 in 2012, and even then there were some baffling and massively unnecessarily migration-hostile decisions like not allowing a separate PYTHON3PATH envvar. Anyway, how hard would it have been to have a "from __past__ import old_strings" that could have worked for the first few releases to allow the single biggest issue to be smoothed over universally and then fixed file by file under the Python 3 environment? With that in place a lot of shops could have just migrated on day 1 and then iteratively worked to finish the job rather than delaying for so long.

mynameisvlad 6y ago
I mean, that's still 8 years of time to migrate to Python 3. That's more than enough time, IMO.
- mikepurvis 6y ago
  Right but it poisoned the well; people had already had four years to kick the tires and conclude "yeah nothing works, my dependencies aren't ready; this seems completely not worth it."
  - dxdm 6y ago
    That doesn't sound like a good reason to sit on your butt for 8 more years while the world moves on.
    - mikepurvis 6y ago
      At this point we're hopefully past insulting people who did what everyone else did and instead looking for the larger patterns and lessons learned.
      - mynameisvlad 6y ago
        Saying that people sat on their butt for 8 years is insulting now? Come on. At the end of the day, they had anywhere from 8 to 12 years to migrate. In the tech world, that's a millennia. Most products and services will give you months when they deprecate or sunset.
        mikepurvis 6y ago
        I'm just saying that criticizing individual people or groups is irrelevant when it was so widespread. Clearly the problems are/were systemic, so it's more productive to focus on the systemic causes than blaming individuals.
maxerickson 6y ago
It would mean shipping 2 interpreters and libraries.
- yjftsjthsd-h 6y ago
  We did that. Every Linux distribution I've ever seen had packages for python 2 and 3 that expected to be installed next to each other as needed.
  - maxerickson 6y ago
    Sure, but it would have to be a single executable with 2 interpreters inside of it to support some sort of incremental upgrade path, which is what the comment I replied to is talking about (they are asking for something that didn't get made). And then you have to decide if they can talk to each other or what.
    - yjftsjthsd-h 6y ago
      Oh, a module level 2/3 split, or even finer than that. Okay, I agree that that would have helped the transition, at the cost of being a pain to implement (if it's even reasonable, ex. I'm not sure what to do if a py2 function passes a string to a py3 function)
    - mikepurvis 6y ago
      Wouldn't have had to be the whole interpreter, really just a flag with single file scope which makes bare strings be interpreted as bytes instead of str, and maybe some other similar translations in stdlib functions.
xxpor 6y ago
Just use 2to3. That's the most trivial problem to solve.
- pseudalopex 6y ago
  2to3 needs manual assistance. Most projects couldn't drop Python 2 right away.
  - mikepurvis 6y ago
    Yeah, it was definitely not just as easy as a machine translation, especially when dealing with which library functions took one vs the other. And this attitude and lack of empathy ("just use the automated tool, lol") is a big part of why the blasted thing took so long.
    - xxpor 6y ago
      I was refering specifically to the complaint about print vs print(). 2to3 will take care of that.
pseudalopex 6y ago
Separating text and byte strings was the reason for Python 3. The other changes were just taking advantage of the compatibility break.
- user5994461 6y ago
  And some of the other changes should not have happened. Personally I still have a sour taste of the urllib migration. All the imports were moved around for no reasons, completely breaking all usage of urllib and any "import urllib", with no way to fix in sight. The solution came with six a million years later, adding a hundred alias in six.moves.urllib.somefunction that dispatch to the right place.

mynameisvlad 6y ago

I mean, that's still 8 years of time to migrate to Python 3. That's more than enough time, IMO.

mikepurvis 6y ago
Right but it poisoned the well; people had already had four years to kick the tires and conclude "yeah nothing works, my dependencies aren't ready; this seems completely not worth it."
- dxdm 6y ago
  That doesn't sound like a good reason to sit on your butt for 8 more years while the world moves on.
  - mikepurvis 6y ago
    At this point we're hopefully past insulting people who did what everyone else did and instead looking for the larger patterns and lessons learned.
    - mynameisvlad 6y ago
      Saying that people sat on their butt for 8 years is insulting now? Come on. At the end of the day, they had anywhere from 8 to 12 years to migrate. In the tech world, that's a millennia. Most products and services will give you months when they deprecate or sunset.
      - mikepurvis 6y ago
        I'm just saying that criticizing individual people or groups is irrelevant when it was so widespread. Clearly the problems are/were systemic, so it's more productive to focus on the systemic causes than blaming individuals.

maxerickson 6y ago

It would mean shipping 2 interpreters and libraries.

yjftsjthsd-h 6y ago
We did that. Every Linux distribution I've ever seen had packages for python 2 and 3 that expected to be installed next to each other as needed.
- maxerickson 6y ago
  Sure, but it would have to be a single executable with 2 interpreters inside of it to support some sort of incremental upgrade path, which is what the comment I replied to is talking about (they are asking for something that didn't get made). And then you have to decide if they can talk to each other or what.
  - yjftsjthsd-h 6y ago
    Oh, a module level 2/3 split, or even finer than that. Okay, I agree that that would have helped the transition, at the cost of being a pain to implement (if it's even reasonable, ex. I'm not sure what to do if a py2 function passes a string to a py3 function)
  - mikepurvis 6y ago
    Wouldn't have had to be the whole interpreter, really just a flag with single file scope which makes bare strings be interpreted as bytes instead of str, and maybe some other similar translations in stdlib functions.

xxpor 6y ago

Just use 2to3. That's the most trivial problem to solve.

pseudalopex 6y ago
2to3 needs manual assistance. Most projects couldn't drop Python 2 right away.
- mikepurvis 6y ago
  Yeah, it was definitely not just as easy as a machine translation, especially when dealing with which library functions took one vs the other. And this attitude and lack of empathy ("just use the automated tool, lol") is a big part of why the blasted thing took so long.
  - xxpor 6y ago
    I was refering specifically to the complaint about print vs print(). 2to3 will take care of that.

pseudalopex 6y ago

Separating text and byte strings was the reason for Python 3. The other changes were just taking advantage of the compatibility break.

user5994461 6y ago
And some of the other changes should not have happened. Personally I still have a sour taste of the urllib migration. All the imports were moved around for no reasons, completely breaking all usage of urllib and any "import urllib", with no way to fix in sight. The solution came with six a million years later, adding a hundred alias in six.moves.urllib.somefunction that dispatch to the right place.