3 ms·

The science stack is also the one that starting migrating the earliest. Hell, numpy started supporting Python 3 eight years ago, while five years ago people wer

The science stack is also the one that starting migrating the earliest. Hell, numpy started supporting Python 3 eight years ago, while five years ago people were still complaining so much they got the EOL delayed. Not saying there are not some specific things that were late or never happened, but again, they are about a minority of projects. The thing is this minority is making all the noise. Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered. Again, it's important to remember you can't make everybody happy, especially if your job is important. If porting is easy for 90% of projects, you did a great work, period. 10% of millions of users having it hard is still going to raise a lot of voices against you by the sheer power of numbers, but you did ok. There is also dishonesty. Most people reporting this problem or that problem didn't actually encounter it. They are reporting somebody else experience they heard about because they wanted to make a point. Or vaguely tried something and ran away after they saw 10 minutes of fiddling didn't solve it. In 10 years going from company to company, I met only 2 projects that were hard to port, but much, much more complainers. When I looked at what was really going on, the fact was just that they were afraid to port, and so just repeated all the stuff other people told them would go wrong. Or they tried running a few scripts for 5 minutes on Python 3 and gave up seeing too many error messages. I know there are honest situations in the lot. But again, the most honest people are not making noise, because they just ported their code and noticed it wasn't the hardship they've been told.

deleted 7y ago
[deleted]
gridlockd 7y ago
> The science stack is also the one that starting migrating the earliest. ...but the last to actually finish migrating. In fact, it's still ongoing. > Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Everyone had to use an inferior version of Python, whether it was because library choice was limited (Python3) or because the language was intentionally left without feature backports (Python2). There was a huge amount of plain "brokenness" in the ecosystem and it was a huge waste of everyone's time.
- joshuamorton 7y ago
  Which common parts of the science stack are still partially two-only? Conda ships on 3.7, and I'd consider it the definitive "scientific" stack.
  - gridlockd 7y ago
    You're right, most packages appear to be Python3 now. Nevertheless, a lot of client code has been written for the Python2 stack and it's still in widespread use. That stuff won't get migrated soon, if ever. Security doesn't really matter there anyway.
- sametmax 7y ago
  > Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Updating software version is part of the job. Like creating tests, writing documentation, training newbies and dealing with customers. It's not hard just because we don't like to do it. Porting to Python 3 was not hard for most people. They just really, really didn't want to do it. I get it. I didn't want to add that on my plate too. Like I didn't want to migrate from my Centos 7, I didn't want to move from mysql to postgres and I didn't want to learn the entire setup of Webpack. 3 times. But "suffering" is a big word that has no place for the vast majority of projects.
  - gridlockd 7y ago
    Like I said, it is not just about updating software. You can't realistically update all your dependencies by yourself. You are stuck with a tough choice: Do I start out with Python3 and tons of broken packages? Do I limit myself to Python2 and face a costly migration later on? Do I run the extra cost of supporting both? This the choice you had face for the better part of ten years of migration. Perhaps it's not obvious that all Python-based software was worse for it, but that's what happened. I'm not talking about some web backend service where most of what you do is trivial stuff. You can write and re-write that in almost anything, it doesn't matter.

deleted 7y ago

[deleted]

gridlockd 7y ago

> The science stack is also the one that starting migrating the earliest. ...but the last to actually finish migrating. In fact, it's still ongoing. > Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Everyone had to use an inferior version of Python, whether it was because library choice was limited (Python3) or because the language was intentionally left without feature backports (Python2). There was a huge amount of plain "brokenness" in the ecosystem and it was a huge waste of everyone's time.

joshuamorton 7y ago
Which common parts of the science stack are still partially two-only? Conda ships on 3.7, and I'd consider it the definitive "scientific" stack.
- gridlockd 7y ago
  You're right, most packages appear to be Python3 now. Nevertheless, a lot of client code has been written for the Python2 stack and it's still in widespread use. That stuff won't get migrated soon, if ever. Security doesn't really matter there anyway.
sametmax 7y ago
> Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Updating software version is part of the job. Like creating tests, writing documentation, training newbies and dealing with customers. It's not hard just because we don't like to do it. Porting to Python 3 was not hard for most people. They just really, really didn't want to do it. I get it. I didn't want to add that on my plate too. Like I didn't want to migrate from my Centos 7, I didn't want to move from mysql to postgres and I didn't want to learn the entire setup of Webpack. 3 times. But "suffering" is a big word that has no place for the vast majority of projects.
- gridlockd 7y ago
  Like I said, it is not just about updating software. You can't realistically update all your dependencies by yourself. You are stuck with a tough choice: Do I start out with Python3 and tons of broken packages? Do I limit myself to Python2 and face a costly migration later on? Do I run the extra cost of supporting both? This the choice you had face for the better part of ten years of migration. Perhaps it's not obvious that all Python-based software was worse for it, but that's what happened. I'm not talking about some web backend service where most of what you do is trivial stuff. You can write and re-write that in almost anything, it doesn't matter.