5 ms·

Again with the 'Tremendous amount of effort' meme. I've done many ports and they were all trivial: - run 2to3 - spend 2h max fixing any failing tests

Again with the 'Tremendous amount of effort' meme. I've done many ports and they were all trivial: - run 2to3 - spend 2h max fixing any failing tests - cook of any remaining issues in a few days of beta testing like you'd do for any new release Now now doubt Python 2.7 is a excellent and solid release and will remain so for as long anyone keeps the bitrot in check, but to keep using it because porting is 'hard' is patent bs.

jordigh 7y ago
Behold the tremendous amount of effort for Mercurial: https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2000 https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2... They've been porting hg into Python 3 for the last 10 years and are only now nearing completion. I've written a bit more about this in Lobsters: https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_my_systems#c_tscufo https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_...
- ageofwant 7y ago
  Yes of course there will be exceptions. But the vast majority off Python code bases are not mercurial or dropbox or imgur. Just like the vast majority of software using companies are not google or facebook. The average few hundred to few thousand loc app, which should be 98% of all production code-bases will almost certainly port with no issue.
  - ben_jones 7y ago
    You're assuming a lot. What about codebases with python2 third party dependencies that don't work in python3? Now you have to port that entire library as well, or write it yourself while crossing your fingers that it is well documented and easy to work through. What about codebases without decent test suites? I'd argue most production codebases don't have good test suites, or at least the most complex of code is usually poorly tested. You'll end up spending most of your time digging for regressions especially if your code creates large amounts of user interfaces. What about code bases that were written by scientists, mathematicians, or other professionals who may not be as fluent in writing "good" code?
    - ageofwant 7y ago
      It happens... but maybe you are assuming to little. There are almost no relevant 3'rd party libs that has not been ported at this stage. If they have not they probably have been abandoned and the client codebase have bigger issues. Same for uncovered code bases, and 'unprofessional' Python production code. That's hardly Python's fault.
    - your-nanny 7y ago
      dependency rot is a more general problem. in my work we deal with lots of seldomly used applications, and I've found that reducing external dependencies tends to keep life happier
  - Camillo 7y ago
    Maybe now. When python3 came out, anything that touched the filesystem was a hideous mess to port. Let's say you have a simple script that takes a file name as an argument, reads the file, prints some message to stdout (which includes the name of the file), and creates a new output file whose name is based on the name of the first file. In python2, that's trivial. Whatever system you're on would normally be configured so that filename bytes dumped to the terminal would be displayed correctly, so you could just treat the strings as bytes and it would be fine. In python3, it was a nightmare. No, you could not just decode from/encode to UTF-8, even if that was what your system used! Python had its own idea of what the encoding of the terminal was, and if you used the wrong one, it wouldn't let you print. And if you tried to convert from UTF-8 to whatever it thought the terminal was using, it would also break, because not all characters were representable. And your script could just not tell Python to treat the terminal as UTF-8, either; you had to start digging into locale settings, and if you tried to fix those, then _everything else_ would break, and nobody had any idea what the right thing to do was, because you were using an obscure OS (the latest macOS at the time). I assume that it works better now.
  - pbreit 7y ago
    No one wants to spend a ton of energy just to remain in place. I don't understand how software providers are so cavalier about eschewing backwards compatibility.
- Smithalicious 7y ago
  Honest question, how can it possibly take 10 years to port hg to Python 3? If I am to believe the Wikipedia source for the first release of Mercurial[0], it would've been only 4 years old at the start of the 10 year porting process. How on earth does it take 10 years to port 4 year old software? Even taking into account the fact that new features were still being added and not all focus was on porting, this doesn't really seem like a reasonable representation of what's going on; I have a suspicion that "10 years" of porting here does not entail nearly as much work as it seems. [0] https://lkml.org/lkml/2005/4/20/45 https://lkml.org/lkml/2005/4/20/45
  - jordigh 7y ago
    Please follow the links to answer your questions. That should help.
Johnny555 7y ago
It's not so much that it's "hard", but that it's time consuming when you have hundreds or even thousands of python scripts to port -- and since those scripts already work and you probably weren't going to have to touch them at all, you're not really gaining anything for all of that porting effort.
- michaelmrose 7y ago
  Maybe whomever should have stopped writing new ones by 2009 a decade ago. Then you wouldn't have much to port.
  - Johnny555 7y ago
    If you'd have been writing python a decade ago, you'd know why people couldn't transition immediately to Python 3 even if they wanted to. I no longer work for the company that has hundreds of Python scripts left to migrate, but I don't think all of libraries needed (including some API libraries from vendors) were ported to python3 until a few years ago.
CriticalCathed 7y ago
would you be willing to port my 796,113 line program for two hours of pay at $45.00/ hour? Because if so it would be a bargain to hire you. Last time I tried to plan the conversion by looking over the codebase it took me two days of concerted effort to just come to the conclusion that it wasn't worth the effort.
JshWright 7y ago
What's the largest codebase you've migrated?

jordigh 7y ago

Behold the tremendous amount of effort for Mercurial: https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2000 https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2... They've been porting hg into Python 3 for the last 10 years and are only now nearing completion. I've written a bit more about this in Lobsters: https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_my_systems#c_tscufo https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_...

ageofwant 7y ago
Yes of course there will be exceptions. But the vast majority off Python code bases are not mercurial or dropbox or imgur. Just like the vast majority of software using companies are not google or facebook. The average few hundred to few thousand loc app, which should be 98% of all production code-bases will almost certainly port with no issue.
- ben_jones 7y ago
  You're assuming a lot. What about codebases with python2 third party dependencies that don't work in python3? Now you have to port that entire library as well, or write it yourself while crossing your fingers that it is well documented and easy to work through. What about codebases without decent test suites? I'd argue most production codebases don't have good test suites, or at least the most complex of code is usually poorly tested. You'll end up spending most of your time digging for regressions especially if your code creates large amounts of user interfaces. What about code bases that were written by scientists, mathematicians, or other professionals who may not be as fluent in writing "good" code?
  - ageofwant 7y ago
    It happens... but maybe you are assuming to little. There are almost no relevant 3'rd party libs that has not been ported at this stage. If they have not they probably have been abandoned and the client codebase have bigger issues. Same for uncovered code bases, and 'unprofessional' Python production code. That's hardly Python's fault.
  - your-nanny 7y ago
    dependency rot is a more general problem. in my work we deal with lots of seldomly used applications, and I've found that reducing external dependencies tends to keep life happier
- Camillo 7y ago
  Maybe now. When python3 came out, anything that touched the filesystem was a hideous mess to port. Let's say you have a simple script that takes a file name as an argument, reads the file, prints some message to stdout (which includes the name of the file), and creates a new output file whose name is based on the name of the first file. In python2, that's trivial. Whatever system you're on would normally be configured so that filename bytes dumped to the terminal would be displayed correctly, so you could just treat the strings as bytes and it would be fine. In python3, it was a nightmare. No, you could not just decode from/encode to UTF-8, even if that was what your system used! Python had its own idea of what the encoding of the terminal was, and if you used the wrong one, it wouldn't let you print. And if you tried to convert from UTF-8 to whatever it thought the terminal was using, it would also break, because not all characters were representable. And your script could just not tell Python to treat the terminal as UTF-8, either; you had to start digging into locale settings, and if you tried to fix those, then _everything else_ would break, and nobody had any idea what the right thing to do was, because you were using an obscure OS (the latest macOS at the time). I assume that it works better now.
- pbreit 7y ago
  No one wants to spend a ton of energy just to remain in place. I don't understand how software providers are so cavalier about eschewing backwards compatibility.
Smithalicious 7y ago
Honest question, how can it possibly take 10 years to port hg to Python 3? If I am to believe the Wikipedia source for the first release of Mercurial[0], it would've been only 4 years old at the start of the 10 year porting process. How on earth does it take 10 years to port 4 year old software? Even taking into account the fact that new features were still being added and not all focus was on porting, this doesn't really seem like a reasonable representation of what's going on; I have a suspicion that "10 years" of porting here does not entail nearly as much work as it seems. [0] https://lkml.org/lkml/2005/4/20/45 https://lkml.org/lkml/2005/4/20/45
- jordigh 7y ago
  Please follow the links to answer your questions. That should help.

Johnny555 7y ago

It's not so much that it's "hard", but that it's time consuming when you have hundreds or even thousands of python scripts to port -- and since those scripts already work and you probably weren't going to have to touch them at all, you're not really gaining anything for all of that porting effort.

michaelmrose 7y ago
Maybe whomever should have stopped writing new ones by 2009 a decade ago. Then you wouldn't have much to port.
- Johnny555 7y ago
  If you'd have been writing python a decade ago, you'd know why people couldn't transition immediately to Python 3 even if they wanted to. I no longer work for the company that has hundreds of Python scripts left to migrate, but I don't think all of libraries needed (including some API libraries from vendors) were ported to python3 until a few years ago.

CriticalCathed 7y ago

would you be willing to port my 796,113 line program for two hours of pay at $45.00/ hour? Because if so it would be a bargain to hire you. Last time I tried to plan the conversion by looking over the codebase it took me two days of concerted effort to just come to the conclusion that it wasn't worth the effort.

JshWright 7y ago

What's the largest codebase you've migrated?