4 ms·

> It boggles the imagination that anybody is still clinging to Python 2 at this point in the game. I guess they have their reasons, but man, oh man... from an o

> It boggles the imagination that anybody is still clinging to Python 2 at this point in the game. I guess they have their reasons, but man, oh man... from an outsider perspective, this feels very questionable. If you're running a company would you prefer to ask your developers to spend their time upgrading to Python 3 for mostly syntactical sugar or adding new features? Python 3 is a complete disaster. It's not a newer version of the language, it's an entirely different language.

mariuolo 7y ago
> Python 3 is a complete disaster. It's not a newer version of the language, it's an entirely different language. Be news to me. Are you sure you aren't talking about Perl 6?
mindcrime 7y ago
Python is (or will soon be) unsupported, legacy technology with no future. If I had a Python 2 codebase, I'd be asking the developers to move to a platform with a future. And while I disagree with your "Python 3 is an entirely new language" assessment, even if that were true, the point would be the same: move to a modern platform, whether it's Python3, Go, Rust, Java, Erlang, Agda, Brainfuck, or whatever.
- speedplane 7y ago
  > If I had a Python 2 codebase, I'd be asking the developers to move to a platform with a future. You've obviously never managed a production app with paying customers on a Python 2 codebase. In a real product, there are a near infinite number of bugs to fix and features to add. Each new feature or bug fix can often lead to additional customers and more revenue. In contrast, re-engineering a large Python 2 codebase into Python 3 can take a team months, and users won't notice the difference. If you were a product manager, or even a technical systems architect, would you prefer that your devs make the product more useful to your customers or would you ask them to devote their time to rewriting already working code for a different programming language?
  - tutfbhuf 7y ago
    In software development there are direct short term goals and benefits, like bug fixes and features, which easily show up in the next quarter result and there are long term objectives which are hard to measure but equally important. If a company only focus on short term quick wins, then it will most likely not survive in the long run. One reason for this is that as the software/stack gets outdated it becomes much harder to find new good developers that want to spend a significant time of their life with legacy software and stuck on a dead end language like phyton 2.7 with no future. Eventually the niche will be covered by a new company with an up-to-date tech stack. Uprading the codebase from python 2.7 to 3.X definitely only pays (the bill) in the long run. If a company plans to shutdown one of their department anyway within the next few years, well then stick to python 2.7 and die along with it. But if a company plans to continue for the next decade, then the upgrade to python 3 is a no-brainer.
    - speedplane 7y ago
      > Uprading the codebase from python 2.7 to 3.X definitely only pays (the bill) in the long run. It doesn't even pay the long term bills. If future development necessitates the use of Python 3, it is far easier and more maintainable to put the existing app into a Python 2 Docker container, and build any new stuff in Python 3 container. If they have to talk to each other, they can do so using standard inter process communication techniques. You are underestimating the amount of work it takes to rewrite a large app. History is littered with examples of rewrites taking down entire products and companies. There are almost always better solutions.
      - tutfbhuf 7y ago
        When we talk about rewrites I absolutely agree. As for example there have been many attempts in the financial sector to rewrite million lines of COBOL code running on mainframes for decades. Many of those attempts failed and they probably will run COBOL indefinitely / until the code isn't useful anymore. To throw away the entire code base and start from scratch in a completely different and non compatible language, isn't a smart idea in many cases, agreed. But we don't talk about a rewrite. One very obvious difference is, that you are able to migrate slowly, by writing python code that runs on both python 2 and 3. It's possible to slowly increase the percentage of python 3 compatible code in your codebase until it reaches 100%. Many huge code bases have been successfully migrated this way, and there is no obvious reason to me against such an slow migration, again except you want to shutdown your company in 2020 anyway.

mariuolo 7y ago

> Python 3 is a complete disaster. It's not a newer version of the language, it's an entirely different language. Be news to me. Are you sure you aren't talking about Perl 6?

mindcrime 7y ago

Python is (or will soon be) unsupported, legacy technology with no future. If I had a Python 2 codebase, I'd be asking the developers to move to a platform with a future. And while I disagree with your "Python 3 is an entirely new language" assessment, even if that were true, the point would be the same: move to a modern platform, whether it's Python3, Go, Rust, Java, Erlang, Agda, Brainfuck, or whatever.

speedplane 7y ago
> If I had a Python 2 codebase, I'd be asking the developers to move to a platform with a future. You've obviously never managed a production app with paying customers on a Python 2 codebase. In a real product, there are a near infinite number of bugs to fix and features to add. Each new feature or bug fix can often lead to additional customers and more revenue. In contrast, re-engineering a large Python 2 codebase into Python 3 can take a team months, and users won't notice the difference. If you were a product manager, or even a technical systems architect, would you prefer that your devs make the product more useful to your customers or would you ask them to devote their time to rewriting already working code for a different programming language?
- tutfbhuf 7y ago
  In software development there are direct short term goals and benefits, like bug fixes and features, which easily show up in the next quarter result and there are long term objectives which are hard to measure but equally important. If a company only focus on short term quick wins, then it will most likely not survive in the long run. One reason for this is that as the software/stack gets outdated it becomes much harder to find new good developers that want to spend a significant time of their life with legacy software and stuck on a dead end language like phyton 2.7 with no future. Eventually the niche will be covered by a new company with an up-to-date tech stack. Uprading the codebase from python 2.7 to 3.X definitely only pays (the bill) in the long run. If a company plans to shutdown one of their department anyway within the next few years, well then stick to python 2.7 and die along with it. But if a company plans to continue for the next decade, then the upgrade to python 3 is a no-brainer.
  - speedplane 7y ago
    > Uprading the codebase from python 2.7 to 3.X definitely only pays (the bill) in the long run. It doesn't even pay the long term bills. If future development necessitates the use of Python 3, it is far easier and more maintainable to put the existing app into a Python 2 Docker container, and build any new stuff in Python 3 container. If they have to talk to each other, they can do so using standard inter process communication techniques. You are underestimating the amount of work it takes to rewrite a large app. History is littered with examples of rewrites taking down entire products and companies. There are almost always better solutions.
    - tutfbhuf 7y ago
      When we talk about rewrites I absolutely agree. As for example there have been many attempts in the financial sector to rewrite million lines of COBOL code running on mainframes for decades. Many of those attempts failed and they probably will run COBOL indefinitely / until the code isn't useful anymore. To throw away the entire code base and start from scratch in a completely different and non compatible language, isn't a smart idea in many cases, agreed. But we don't talk about a rewrite. One very obvious difference is, that you are able to migrate slowly, by writing python code that runs on both python 2 and 3. It's possible to slowly increase the percentage of python 3 compatible code in your codebase until it reaches 100%. Many huge code bases have been successfully migrated this way, and there is no obvious reason to me against such an slow migration, again except you want to shutdown your company in 2020 anyway.