5 ms·

It's not just because we "know and love" Python2. We also have immense legacy Python2 codebases that it would be time-consuming and risky to upgrade to Python3

It's not just because we "know and love" Python2. We also have immense legacy Python2 codebases that it would be time-consuming and risky to upgrade to Python3. And we have other business priorities we have to pursue. As long as Python2 is viable. Which it still is and probably will be for quite a while. (Even once official support for it is dropped, there will undoubtedly be large enterprises that rely on it and will continue to maintain forks.)

sametmax 10y ago
This is why the Python community gave 15 years to migrate. This is why we created many, many tools (2to3, six, Python-future, mypy) to help with it. And this is why Guido is always saying 2.7 users are important and need respect. Still. 15 years. It's not a last minute change. Python has been incredible in maintaining the 2.7 around, giving people help and time to change. I know NO other tech that did that. The JS community breaks his toys every other week. PHP just jumped a version to avoid it. No one is migrating to Perl 6. Python is actually the only one that pulled this off, and have been very, very careful to give you the margin to do it. Everything needs to evolve, and one day you will have to do it. Don't to it in 2020, or it will be way more costly. And yes, you have many advantages in having Python 3, mainly ease of dev, debug and maintenance. This is not as hard as it seems. Took me a week alone to convert a huge system. Don't feel overwhelmed by the task, it's really not the end of the world.
- cauterized 10y ago
  And when you have almost a million lines of code dating back 10 years; about 3% test coverage; and an executive team breathing down your neck to implement the features that should have been prioritized 5 years ago by the "leadership" they bought the company from? When you have 3 engineers, one of whom is working full time on bugfixes and preventing everything from catching fire and one of whom is working full time on applying the second of 8 major versions' worth of upgrades to your framework (along with third-party dependencies that have to be version-compatible) just to catch up to a version that's still maintained with security patches? When every framework/library upgrade, let alone language version upgrade exposes subtle backwards-incompatibilities with your external services, so you have to upgrade those too, and then spend 2 weeks understanding and solving the resulting forwards-incompatibilities? Just because it was easy for you and your codebase doesn't mean it's going to be easy for everyone else. I'm not saying we'll never doing it. I'm sure as hell not saying we (being the engineering team) don't want to do it. I'm saying we haven't done it yet because we can't do it at all until we complete the other upgrades. We can't do it at all without spending a week or three months or however long finding or writing replacements for crappy (and in a few cases not so crappy) abandoned third-party packages that aren't and never will be supported under Python3. We can't do it until we can spare 3 months from our timeline to exhaustively click-through test the damn thing and verify we haven't broken anything. And saying we had 15 years to migrate is bullshit. Our major dependencies haven't been stable on Python3 for more than about 3 years now. By the way, did I mention before that we have other business priorities? Python2 is still supported. It'll continue to be supported for a few more years. Why should we spend valuable time converting to Python3 now, when the other things we're working on could be the difference between whether or not we're still around in a few more years? No, it won't be more costly in 2020. It'll be less costly. We'll have a larger engineering team because we solved more business problems and customer problems, so the business earned more money and could afford to hire more people. Or we'll already be out of business and it will have had nothing to do with which version of Python we were using.
  - sametmax 10y ago
    Here Python 2 vs 3 is not your problem here. You problem is that the project is in very bad shape. Anything that disrupt it will cause you huge problems. Python migration just happen to be the wake up call. No tech can be asked to be calibrated to compensate 20 years of bad project management.
    - cauterized 10y ago
      I'm not blaming the tech. I like Python3 and start new projects in it when I can. Yes, our code base is a giant fucking disaster. I wouldn't even begin to try to deny that. I'm also pretty certain that there are others in the same boat to a greater or lesser degree. I've seen too many codebases that were the product of starting with a team of one or two and a mandate to move quickly. It's impressively easy to dig yourself into this sort of hole, and it's impressively common among startups in my experience. I'd imagine that large enterprises are even more likely to have even larger legacy codebases without full test coverage. They may have more resources to throw at the problem but are also likely to have more political obstacles and even higher standards for verification that they haven't introduced new bugs. But the GP was insisting that there's no reason not to have upgraded yet other than sheer stubbornness and unwillingness to learn new things, or even laziness on the part of the engineers. That's incorrect and insulting.
      - sametmax 10y ago
        Ouch.
- lima 10y ago
  > Took me a week alone to convert a huge system. Can confirm. Porting even huge code bases has become much easier lately thanks to recent changes in Python 3 (unicode literals!) and Python-Future. "from six import u" and many other hacks are no longer necessary. Try it, and there's a huge friendly community there to help you :-)

sametmax 10y ago

This is why the Python community gave 15 years to migrate. This is why we created many, many tools (2to3, six, Python-future, mypy) to help with it. And this is why Guido is always saying 2.7 users are important and need respect. Still. 15 years. It's not a last minute change. Python has been incredible in maintaining the 2.7 around, giving people help and time to change. I know NO other tech that did that. The JS community breaks his toys every other week. PHP just jumped a version to avoid it. No one is migrating to Perl 6. Python is actually the only one that pulled this off, and have been very, very careful to give you the margin to do it. Everything needs to evolve, and one day you will have to do it. Don't to it in 2020, or it will be way more costly. And yes, you have many advantages in having Python 3, mainly ease of dev, debug and maintenance. This is not as hard as it seems. Took me a week alone to convert a huge system. Don't feel overwhelmed by the task, it's really not the end of the world.

cauterized 10y ago
And when you have almost a million lines of code dating back 10 years; about 3% test coverage; and an executive team breathing down your neck to implement the features that should have been prioritized 5 years ago by the "leadership" they bought the company from? When you have 3 engineers, one of whom is working full time on bugfixes and preventing everything from catching fire and one of whom is working full time on applying the second of 8 major versions' worth of upgrades to your framework (along with third-party dependencies that have to be version-compatible) just to catch up to a version that's still maintained with security patches? When every framework/library upgrade, let alone language version upgrade exposes subtle backwards-incompatibilities with your external services, so you have to upgrade those too, and then spend 2 weeks understanding and solving the resulting forwards-incompatibilities? Just because it was easy for you and your codebase doesn't mean it's going to be easy for everyone else. I'm not saying we'll never doing it. I'm sure as hell not saying we (being the engineering team) don't want to do it. I'm saying we haven't done it yet because we can't do it at all until we complete the other upgrades. We can't do it at all without spending a week or three months or however long finding or writing replacements for crappy (and in a few cases not so crappy) abandoned third-party packages that aren't and never will be supported under Python3. We can't do it until we can spare 3 months from our timeline to exhaustively click-through test the damn thing and verify we haven't broken anything. And saying we had 15 years to migrate is bullshit. Our major dependencies haven't been stable on Python3 for more than about 3 years now. By the way, did I mention before that we have other business priorities? Python2 is still supported. It'll continue to be supported for a few more years. Why should we spend valuable time converting to Python3 now, when the other things we're working on could be the difference between whether or not we're still around in a few more years? No, it won't be more costly in 2020. It'll be less costly. We'll have a larger engineering team because we solved more business problems and customer problems, so the business earned more money and could afford to hire more people. Or we'll already be out of business and it will have had nothing to do with which version of Python we were using.
- sametmax 10y ago
  Here Python 2 vs 3 is not your problem here. You problem is that the project is in very bad shape. Anything that disrupt it will cause you huge problems. Python migration just happen to be the wake up call. No tech can be asked to be calibrated to compensate 20 years of bad project management.
  - cauterized 10y ago
    I'm not blaming the tech. I like Python3 and start new projects in it when I can. Yes, our code base is a giant fucking disaster. I wouldn't even begin to try to deny that. I'm also pretty certain that there are others in the same boat to a greater or lesser degree. I've seen too many codebases that were the product of starting with a team of one or two and a mandate to move quickly. It's impressively easy to dig yourself into this sort of hole, and it's impressively common among startups in my experience. I'd imagine that large enterprises are even more likely to have even larger legacy codebases without full test coverage. They may have more resources to throw at the problem but are also likely to have more political obstacles and even higher standards for verification that they haven't introduced new bugs. But the GP was insisting that there's no reason not to have upgraded yet other than sheer stubbornness and unwillingness to learn new things, or even laziness on the part of the engineers. That's incorrect and insulting.
    - sametmax 10y ago
      Ouch.
lima 10y ago
> Took me a week alone to convert a huge system. Can confirm. Porting even huge code bases has become much easier lately thanks to recent changes in Python 3 (unicode literals!) and Python-Future. "from six import u" and many other hacks are no longer necessary. Try it, and there's a huge friendly community there to help you :-)