7 ms·

Forgive my ignorance, but what should have been done instead of the way the Python 2 to 3 migration happened? I know that Python 2 has stuck around for far lon

Forgive my ignorance, but what should have been done instead of the way the Python 2 to 3 migration happened? I know that Python 2 has stuck around for far longer than anyone wanted and that people were (are?) hesitant to migrate from 2 to 3, but I'm not sure what decisions contributed to that.

yjftsjthsd-h 4y ago
IMHO: Early versions of Python 3 were outright inferior, and IIRC couldn't handle raw bytes, because "everything should be Unicode". Except, not everything is Unicode. So people went to port, and couldn't. This compounded a problem with libraries, to create a situation where transitioning was risky. Better yet, eventually the Python devs decreed that everyone should move already... so they were going to stop making new 2.x feature releases, and only issue big fixes. But to the folks already hesitant to change, that sounded a lot like "Python 2 will be super Stable for forever". So IMO, basically what should have happened is accounting for valid use of features that 3 wanted to kill, and actually offering a path forward, from day one, so everyone could do a migration and actually have it work. Edit: Also (but connected), 3.0 (and IIRC a couple thereafter) should have been marked as release candidates, because they were.
- jacquesm 4y ago
  I think you are making some really good points, the fact that the bulk of the initial bugs were found by users and not by the developers is what caused initial adoption of V3 to run into an immediate roadblock. If that had not happened the whole thing might have gone over a lot faster but it caused a lot of people to go from 'Yay, UTF-8 strings' to 'wait and see and let someone else handle the bugs, we'll check back in a year (or two, or five)'.
YetAnotherNick 4y ago
I think the biggest issue was that they named the executable same. They backported few things from python 3 to 2.7, and recommended to use `sys.version_info` and `__future__` for making code run in both python. If they said they would never rename python3 executable to python and python3 is not python, it would have been easier for everyone.
sjducb 4y ago
Just maintain backwards compatibility. For us it was a change in string handling that stopped us being able to upgrade. Literally 10,000 things would have to be checked. We saw that red hat was supporting python 2 until 2025 so we decided to keep using python 2 until then. I think that once red hat stops supporting python 2 someone else will keep it running. Python 2 still makes the world go round.
dontlaugh 4y ago
They should have made the Python 3 interpreter able to embed the Python 2 interpreter. It would’ve then been possible to mark projects as 3 while they continue to import 2 libraries.
- maxbond 4y ago
  This is similar to Rust's approach of using language "editions" separately from compiler versions (presumably because they learned from this migration).

yjftsjthsd-h 4y ago

IMHO: Early versions of Python 3 were outright inferior, and IIRC couldn't handle raw bytes, because "everything should be Unicode". Except, not everything is Unicode. So people went to port, and couldn't. This compounded a problem with libraries, to create a situation where transitioning was risky. Better yet, eventually the Python devs decreed that everyone should move already... so they were going to stop making new 2.x feature releases, and only issue big fixes. But to the folks already hesitant to change, that sounded a lot like "Python 2 will be super Stable for forever". So IMO, basically what should have happened is accounting for valid use of features that 3 wanted to kill, and actually offering a path forward, from day one, so everyone could do a migration and actually have it work. Edit: Also (but connected), 3.0 (and IIRC a couple thereafter) should have been marked as release candidates, because they were.

jacquesm 4y ago
I think you are making some really good points, the fact that the bulk of the initial bugs were found by users and not by the developers is what caused initial adoption of V3 to run into an immediate roadblock. If that had not happened the whole thing might have gone over a lot faster but it caused a lot of people to go from 'Yay, UTF-8 strings' to 'wait and see and let someone else handle the bugs, we'll check back in a year (or two, or five)'.

YetAnotherNick 4y ago

I think the biggest issue was that they named the executable same. They backported few things from python 3 to 2.7, and recommended to use `sys.version_info` and `__future__` for making code run in both python. If they said they would never rename python3 executable to python and python3 is not python, it would have been easier for everyone.

sjducb 4y ago

Just maintain backwards compatibility. For us it was a change in string handling that stopped us being able to upgrade. Literally 10,000 things would have to be checked. We saw that red hat was supporting python 2 until 2025 so we decided to keep using python 2 until then. I think that once red hat stops supporting python 2 someone else will keep it running. Python 2 still makes the world go round.

dontlaugh 4y ago

They should have made the Python 3 interpreter able to embed the Python 2 interpreter. It would’ve then been possible to mark projects as 3 while they continue to import 2 libraries.

maxbond 4y ago
This is similar to Rust's approach of using language "editions" separately from compiler versions (presumably because they learned from this migration).