7 ms·

> I really don't think Python was close to dying It absolutely was. What saved it was: 1. The data science / AI crowd that was gathering momentum any many onl

by foofoo12 10mo ago

> I really don't think Python was close to dying It absolutely was. What saved it was: 1. The data science / AI crowd that was gathering momentum any many only used Python 3. 2. No popular alternative. Perl got python as an alternative. Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.

mixmastamyk 10mo ago
I was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first. None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.
- selcuka 10mo ago
  Porting your own code was relatively easy. The problem was porting all your dependencies, and replacing the ones that were abandoned and didn't support 3.x.
  - mixmastamyk 10mo ago
    I did wait a bit for Django and SQLAlchemy but it wasn't long, they may have been ready for 3.6. Small deps were replaced or eliminated.
    - masklinn 10mo ago
      They were ready long before 3.6, sqlalchemy added support for Python 3.1 in 0.6, and Django 1.5 introduced support for Python 3.2 on an experimental basis with 1.6 removing the “experimental” bit.
dist-epoch 10mo ago
You're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?
nine_k 10mo ago
Python 2.7 was kept very much alive, with a number of small improvements from the 3.x branch backported to it. Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x. The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects. Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
- Izkata 10mo ago
  > the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects. Python 2 had both, it was a rename, not a split. unicode -> str, and str -> bytes. The "u" string prefix was also removed, which made migration of string-heavy code more of a pain than it needed to be, until it was added back in in 3.3
tptacek 10mo ago
Long before the AI/data science breakout, we were noticing in our consulting practice (2016-2020) a sharp dropoff in Ruby at startups, and Python as the modal language (by the time I left in 2020, it would have gone Python -> Node -> Ruby). So no, I don't think AI saved Python; it was fine before then.
- smohare 10mo ago
  2016 already puts one far into the AI explosion. The current hype cycle, with LLMs as a service at the forefront, arguably makes python less relevant than in it was in the mid 2010’s. The current crop of “AI Engineers” can use whatever languages they want for the most part. In 2016 most practitioners were leveraging a lot more of the standard scientific computing frameworks afforded by python.
  - tptacek 10mo ago
    Python was the lingua franca of data science by 2016, but AI and data science was clearly not the reason startups were building in Django and Flask --- the data science teams were always a morass of Jupyter notebooks and pickle blobs.
MoonWalk 10mo ago
I don't know. Isn't Python still viewed as a mess now? I was thinking of taking the time to learn it as the best way to write cross-platform utilities, but encountered a lot of negative sentiment about its ecosystem. And all the environment managers you seem to need for it are a turn-off. Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
- kstrauser 10mo ago
  It's vastly improved now. With uv, many times you can download a new utility off GitHub and run it with `uv run foo.py`, including fetching its dependencies.
  - MoonWalk 10mo ago
    Cool, thanks!
- jujube3 10mo ago
  Python is great for data science. Anything where you need to wrap a C library like BLAS, tensorflow, PyTorch, matplotlib, numpy. It's hot garbage for writing simple cross-platform utilities because of the need for an elaborate environment setup, painful dependency management, and constant compatibility breaks.
- graemep 10mo ago
  Its much exaggerated. Its got a big standard library so you can do a lot by just installing Python. On a lot of *nix systems it will all be installed already. For simple use cases you do not have to have the environment manager. I have had few problems with virtualenv in any case. Where you are most likely to have problems is cross platform deployment. If you are going to package it as an exe for Windows users, and package it for major Linux distros, and whatever you need to do for MacOS etc. its going to be a pain. In that case there are multiple languages that might suit you better than JS.
- 10mo ago
skylurk 10mo ago
> No popular alternative I can easily imagine a scenario where Julia could have taken the data science crowd and Node.js could have taken everyone else. People like Python, I guess.
- foofoo12 10mo ago
  Before JS had promises, JS code was plagued with the callback pyramid of doom. You needed an advanced masters degree in masochism to endure that. I don't think Python devs would have liked that.
matthewmc3 10mo ago
You forgot perhaps the most important one: 3. six `six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.
- masklinn 10mo ago
  Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's). In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
  - saurik 10mo ago
    > Python 2 features were reintroduced in basically every P3 version until at least 3.5 If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
    - masklinn 10mo ago
culi 10mo ago
IMO javascript was a valid alternative. Easy to learn and easy to run. That's the main things needed for academic work Python had a history of tooling/libraries that made it well ingrained into academia
- maleldil 10mo ago
  Javascript didn't have the same FFI story with C/Fortran as Python. That's what allowed libraries such as numpy, scipy, pandas, etc. to flourish.
drzaiusx11 10mo ago
Anecdotally, I stopped using python for several years around the transition period from 2 to 3 because a number of libraries I used at the time were in flux with 3 support (beautiful soup I _think_ was one? I could be misremembering). Ironically, I ended up just using perl for a scraping tool instead, which it's quite good at for quick and dirty scraping scripts (PCRE.) Nowadays I use ruby for that type of stuff...
kaashif 10mo ago
It was close to dying, except for these two things that mean it definitely wasn't close to dying? "Having no popular alternative" is not something that was close to not happening.

mixmastamyk 10mo ago

I was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first. None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.

selcuka 10mo ago
Porting your own code was relatively easy. The problem was porting all your dependencies, and replacing the ones that were abandoned and didn't support 3.x.
- mixmastamyk 10mo ago
  I did wait a bit for Django and SQLAlchemy but it wasn't long, they may have been ready for 3.6. Small deps were replaced or eliminated.
  - masklinn 10mo ago
    They were ready long before 3.6, sqlalchemy added support for Python 3.1 in 0.6, and Django 1.5 introduced support for Python 3.2 on an experimental basis with 1.6 removing the “experimental” bit.

dist-epoch 10mo ago

You're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?

nine_k 10mo ago

Python 2.7 was kept very much alive, with a number of small improvements from the 3.x branch backported to it. Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x. The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects. Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.

Izkata 10mo ago
> the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects. Python 2 had both, it was a rename, not a split. unicode -> str, and str -> bytes. The "u" string prefix was also removed, which made migration of string-heavy code more of a pain than it needed to be, until it was added back in in 3.3

tptacek 10mo ago

Long before the AI/data science breakout, we were noticing in our consulting practice (2016-2020) a sharp dropoff in Ruby at startups, and Python as the modal language (by the time I left in 2020, it would have gone Python -> Node -> Ruby). So no, I don't think AI saved Python; it was fine before then.

smohare 10mo ago
2016 already puts one far into the AI explosion. The current hype cycle, with LLMs as a service at the forefront, arguably makes python less relevant than in it was in the mid 2010’s. The current crop of “AI Engineers” can use whatever languages they want for the most part. In 2016 most practitioners were leveraging a lot more of the standard scientific computing frameworks afforded by python.
- tptacek 10mo ago
  Python was the lingua franca of data science by 2016, but AI and data science was clearly not the reason startups were building in Django and Flask --- the data science teams were always a morass of Jupyter notebooks and pickle blobs.

MoonWalk 10mo ago

I don't know. Isn't Python still viewed as a mess now? I was thinking of taking the time to learn it as the best way to write cross-platform utilities, but encountered a lot of negative sentiment about its ecosystem. And all the environment managers you seem to need for it are a turn-off. Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.

kstrauser 10mo ago
It's vastly improved now. With uv, many times you can download a new utility off GitHub and run it with `uv run foo.py`, including fetching its dependencies.
- MoonWalk 10mo ago
  Cool, thanks!
jujube3 10mo ago
Python is great for data science. Anything where you need to wrap a C library like BLAS, tensorflow, PyTorch, matplotlib, numpy. It's hot garbage for writing simple cross-platform utilities because of the need for an elaborate environment setup, painful dependency management, and constant compatibility breaks.
graemep 10mo ago
Its much exaggerated. Its got a big standard library so you can do a lot by just installing Python. On a lot of *nix systems it will all be installed already. For simple use cases you do not have to have the environment manager. I have had few problems with virtualenv in any case. Where you are most likely to have problems is cross platform deployment. If you are going to package it as an exe for Windows users, and package it for major Linux distros, and whatever you need to do for MacOS etc. its going to be a pain. In that case there are multiple languages that might suit you better than JS.
10mo ago

skylurk 10mo ago

> No popular alternative I can easily imagine a scenario where Julia could have taken the data science crowd and Node.js could have taken everyone else. People like Python, I guess.

foofoo12 10mo ago
Before JS had promises, JS code was plagued with the callback pyramid of doom. You needed an advanced masters degree in masochism to endure that. I don't think Python devs would have liked that.

matthewmc3 10mo ago

You forgot perhaps the most important one: 3. six `six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.

masklinn 10mo ago
Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's). In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
- saurik 10mo ago
  > Python 2 features were reintroduced in basically every P3 version until at least 3.5 If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
  - masklinn 10mo ago

culi 10mo ago

IMO javascript was a valid alternative. Easy to learn and easy to run. That's the main things needed for academic work Python had a history of tooling/libraries that made it well ingrained into academia

maleldil 10mo ago
Javascript didn't have the same FFI story with C/Fortran as Python. That's what allowed libraries such as numpy, scipy, pandas, etc. to flourish.

drzaiusx11 10mo ago

Anecdotally, I stopped using python for several years around the transition period from 2 to 3 because a number of libraries I used at the time were in flux with 3 support (beautiful soup I _think_ was one? I could be misremembering). Ironically, I ended up just using perl for a scraping tool instead, which it's quite good at for quick and dirty scraping scripts (PCRE.) Nowadays I use ruby for that type of stuff...

kaashif 10mo ago

It was close to dying, except for these two things that mean it definitely wasn't close to dying? "Having no popular alternative" is not something that was close to not happening.