3 ms·

I get a lot of flak for saying this, but I do hope python committers and psf members take a hard look at perl and its demise. Perl had a very similar problem of

I get a lot of flak for saying this, but I do hope python committers and psf members take a hard look at perl and its demise. Perl had a very similar problem of having N equivalent choices for doing the same thing and python for better or worse is heading in the same direction. In the last few yrs of my professional career many projects I worked, were on are migrating python -> golang cuz frankly many people were fed up of python2->3 migration. Not that golang doesnt have it fair share of issues, but the the packaging and deploying aspects of a single binary makes CI/CD and operations a breeze. I hope python makes this is first class citizen in its ecosystem.

KyeRussell 4y ago
These days I don’t think I’m being too brash in saying that anyone dealing with Python 2 to Python 3 transition stuff is so deep in the realm of enterprise abandonware that it’s not worth paying it much attention. Not necessarily including you here! But as someone that went through the transition, I’m certainly not going to deny how much of a shit show it was. And I get a feeling that the two situations were/are caused by the same political / organisational / philosophical factors. I’d be miffed if the Python / PyPA mob got so distracted with their internal politics, certain terse personalities, or the hands-off competition-is-good ideology, that the packaging story makes Python an increasingly unappealing choice. Even worse, we could end up with a packaging ecosystem run by effing Microsoft like the JS people do, because “competition”. And yes I’m totally conflating aspects of packaging here. At least we all settled on PyPi, except for all those that haven’t… :)
- at_a_remove 4y ago
  It is, sadly, not always Enterprise abandonware. The industry I am in is extremely conservative about its upgrades and changes. Between that, our custom software interfacing with the 800 pound gorilla for our market, and a few other things, we're behind. Now, this software depends on a very specific version of ArcGIS. Desktop, not Pro. Not just version 10. Not just version 10.2. But version 10.2.1. If you go look at ESRI's page for Python and 10.2.1, it says, in large and bold letters (which is something ESRI doesn't do in its documentation very often), NOT TO UPGRADE OR CHANGE PYTHON VERSIONS, EVEN A TINY BIT. And that version is 2.7. I couldn't even get pip working when I wanted to install a very old version of lxml I wanted. I guess what I am getting at is, as a language becomes successful and has market penetration, it also seeps down, way far down, in the chain of dependencies. It's the price of success, essentially. I think language maintainers should really pay more attention to that. Just as you know how a program ends up sticking around longer than you originally thought, so too do versions of your language. It is in some ways akin to trying to explain to da Vinci that very far in the future, some of his artworks will adorn clothing and coffee mugs: the good stuff just gets to places you would never dream.
  - ivoflipse 4y ago
    You're situation is related to this: https://pypackaging-native.github.io/key-issues/native-dependencies/geospatial_stack/ https://pypackaging-native.github.io/key-issues/native-depen... Where it is incredibly hard to align various pieces of software spanning OSes, architectures, programming languages. The result is that you have to compile the whole universe for them to work together. In your case that universe is stuck on 2.7 and it will require a large effort to get everything up compatible with a recent Python version
  - plonk 4y ago
    I guessed you worked in GIS before you mentioned ArcGIS. Our old software was tied with QGIS and I worked hard to de-couple. Tying a Python env to these whales is insane. I think a Cython extension or a second process that uses ArcGIS, with a simple interface between them, might be a better choice for the future? Never needed that though.
musicale 4y ago
Python's aggressive deprecation schedule is a major disadvantage compared to languages with greater stability and backward compatibility. Making things better for dozens of maintainers at the expense of millions of users is the wrong tradeoff. Apple does something similar (e.g. with Swift and with iOS), offloading a constant support burden onto developers.

KyeRussell 4y ago

These days I don’t think I’m being too brash in saying that anyone dealing with Python 2 to Python 3 transition stuff is so deep in the realm of enterprise abandonware that it’s not worth paying it much attention. Not necessarily including you here! But as someone that went through the transition, I’m certainly not going to deny how much of a shit show it was. And I get a feeling that the two situations were/are caused by the same political / organisational / philosophical factors. I’d be miffed if the Python / PyPA mob got so distracted with their internal politics, certain terse personalities, or the hands-off competition-is-good ideology, that the packaging story makes Python an increasingly unappealing choice. Even worse, we could end up with a packaging ecosystem run by effing Microsoft like the JS people do, because “competition”. And yes I’m totally conflating aspects of packaging here. At least we all settled on PyPi, except for all those that haven’t… :)

at_a_remove 4y ago
It is, sadly, not always Enterprise abandonware. The industry I am in is extremely conservative about its upgrades and changes. Between that, our custom software interfacing with the 800 pound gorilla for our market, and a few other things, we're behind. Now, this software depends on a very specific version of ArcGIS. Desktop, not Pro. Not just version 10. Not just version 10.2. But version 10.2.1. If you go look at ESRI's page for Python and 10.2.1, it says, in large and bold letters (which is something ESRI doesn't do in its documentation very often), NOT TO UPGRADE OR CHANGE PYTHON VERSIONS, EVEN A TINY BIT. And that version is 2.7. I couldn't even get pip working when I wanted to install a very old version of lxml I wanted. I guess what I am getting at is, as a language becomes successful and has market penetration, it also seeps down, way far down, in the chain of dependencies. It's the price of success, essentially. I think language maintainers should really pay more attention to that. Just as you know how a program ends up sticking around longer than you originally thought, so too do versions of your language. It is in some ways akin to trying to explain to da Vinci that very far in the future, some of his artworks will adorn clothing and coffee mugs: the good stuff just gets to places you would never dream.
- ivoflipse 4y ago
  You're situation is related to this: https://pypackaging-native.github.io/key-issues/native-dependencies/geospatial_stack/ https://pypackaging-native.github.io/key-issues/native-depen... Where it is incredibly hard to align various pieces of software spanning OSes, architectures, programming languages. The result is that you have to compile the whole universe for them to work together. In your case that universe is stuck on 2.7 and it will require a large effort to get everything up compatible with a recent Python version
- plonk 4y ago
  I guessed you worked in GIS before you mentioned ArcGIS. Our old software was tied with QGIS and I worked hard to de-couple. Tying a Python env to these whales is insane. I think a Cython extension or a second process that uses ArcGIS, with a simple interface between them, might be a better choice for the future? Never needed that though.

musicale 4y ago

Python's aggressive deprecation schedule is a major disadvantage compared to languages with greater stability and backward compatibility. Making things better for dozens of maintainers at the expense of millions of users is the wrong tradeoff. Apple does something similar (e.g. with Swift and with iOS), offloading a constant support burden onto developers.