6 ms·

I kind of have the opposite feeling of many other people here... to me, Python is already pretty much perfect for my use, which is things like build scripts and

by mort96 2y ago

I kind of have the opposite feeling of many other people here... to me, Python is already pretty much perfect for my use, which is things like build scripts and random tools I make, plus it's used by a bunch of software I need to compile. The one big problem it has is that it keeps changing. I'll try to compile some dependency that I haven't updated in some time and I'll find that it fails to build because Python changed in some backward incompatible way. Or a tool I made will suddenly start printing deprecation warnings because Python has deprecated a library. I get that for people for whom Python is their main language, all these changes make their lives better. But for me it kinda just gets in the way. Personally, I wish Python would continue to be maintained as is, but stop changing so much. Stop breaking my builds.

Elucalidavah 2y ago
> The one big problem it has is that it keeps changing What prevents you from using an old Python version?
- dijit 2y ago
  Usually us plebs use the system python. With no python version manager (I don’t even know any off the top of my head). Also virtualenvs only get you so far, I’ve come back to many projects on my machine with broken virtualenvs, I guess due to some dynamically linked dependency of python that my system no longer has. :(
  - ok_dad 2y ago
    > With no python version manager (I don’t even know any off the top of my head) Try a tool called `pyenv`. It's pretty great. I pair it with the package manager called `poetry`.
    - Joeboy 2y ago
      Or https://github.com/astral-sh/uv https://github.com/astral-sh/uv can replace both. Various features are tagged as "experimental", and I guess the api might change, but it seems to work already. I have high hopes for it eventually making python's fragmented package management issues go away. Edit: Somebody's going to respond with the XKCD aren't they? I know about the XKCD and I nevertheless have high hopes for `uv`.
    - Izkata 2y ago
      Looks like pyenv does the same thing as asdf, except only for python. https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf And here's a list of everything it supports: https://github.com/asdf-vm/asdf-plugins/tree/master/plugins https://github.com/asdf-vm/asdf-plugins/tree/master/plugins
  - jashmatthews 2y ago
    It's the sledgehammer approach but... Docker?
    - mort96 2y ago
      Using Docker in order to avoid ever updating Python sounds like a great way to end up in severe tech debt tbh
      - p_l 2y ago
        Arguably it was also non-trivial part of why some places started using Docker...
- wakawaka28 2y ago
  Using an old Python version means you're stuck using libraries that work with that version. I think you have to figure out which ones work on your own as well.
  - scrollaway 2y ago
    Because libraries also change, for the same reason as python changes: To keep up with compatibility of newer devices, systems, and usage patterns. Beside, "figure out which ones work" is a solved issue with a package manager such as poetry.
    - rowanG077 2y ago
      That is if all libraries were super stringent in their dependency bounds. Which in my experience no one is. So it's a crapshoot if it will work or not.
      - SOLAR_FIELDS 2y ago
        This is more of an indictment on how bad Python is about mixing system level packages with library dependencies than anything else. The classic example I always give is psycopg2 depending on a system install of Postgres client library.
        imtringued 2y ago
        The irritating thing about python is that since it is mostly glue around C, all the annoying things about C leak through.
    - wakawaka28 2y ago
      It's not a solved issue, as others have pointed out. To elaborate, most packages are not maintained continuously. Some don't get updates anymore and some get updates that break older versions of Python. The authors of these libraries definitely aren't rooting out all the problems that can occur due to mismatched versions. And when you change one library, any other related library can be affected. It's like solving a puzzle sometimes. In many cases people throw up their hands and say "forget this, I'm not upgrading anything!" This is also the big driver of solutions like virtualenv and Docker. All languages have this issue to some extent but Python breaks stuff more often than anything else I use. I don't especially like language-specific package downloaders either but that's not a Python-only problem, and there are tradeoffs to pushing the work downstream into more stable systems.
- CJefferson 2y ago
  I'd love to stick with python 2.7 forever, but it isn't getting even minor updates just to keep up to date with operating system updates, and is starting to stop being packaged. My current solution is a docker container which includes python 2.7 and a downloaded copy of every package I use.
  - etrautmann 2y ago
    What do you prefer about it?
    - nlitened 2y ago
      That it has a lot of my old code working perfectly for years, and I don't have spare time to port it to another language and keep catching subtle bugs for months.
      - rglullis 2y ago
        Out of curiosity, how many lines of code are we talking about here?
      - imtringued 2y ago
        "Port it to another language". You're saying this as if the minor asinine breaks in python 2 Vs 3 make it a whole new programming language, when in reality it is mostly bullshit like print going from statement to function.
        CJefferson 2y ago
        My problem is some libraries which never transitioned from 2 to 3. I don't want to try to convert them, particularly as they involve Unicode which is one of the hardest bits to get right in my experience.
        skeledrew 2y ago
        Improved unicode (string vs byte separation) handling was exactly one of the larger reasons for the breaking change to 3.
- guappa 2y ago
  > What prevents you from using an old Python version? I think the fact that it's not on the distributions is a major factor here.
- mort96 2y ago
  Being able to use the system's Python (or in the case of macOS, Homebrew's Python) is extremely convenient. Especially when Python is used as a language for build scripts across a team. I'm not interested in forking Python taking on the responsibility of maintaining, packaging and distributing Python across a range of platforms.
scrollaway 2y ago
This reads a bit like "My neighbourhood is already perfect, I wish it would stop changing". Except as a sibling pointed out, you can live in your old unchanging neighbourhood just fine, you don't have to update it. Python changes because of three reasons: Addressing bugs and insecure patterns; support for new usage patterns in the community; updates for compatibility with newer devices and systems. The first one is a given. The second and third are basically "the world is evolving, with or without you". Even if you built a VM on your perfect machine, with your perfect python and perfect libraries and froze everything for 10 years, the moment you connected it to the internet you'd be faced with "Ah, my perfect version does not support this new thingamajig being used on the web". Freezing everything in time is just archiving.
- guappa 2y ago
  > Freezing everything in time is just archiving. None of this explains why python has the need to drop modules for the standard library. They claim "nobody is maintaining them"… but they are well funded and can easily afford someone to maintain them. I think at the core they don't care about backwards compatibility, but instead of doing it all at once like with python2/3 are now doing it little by little, creating a python4 without calling it so.
  - TeMPOraL 2y ago
    > now doing it little by little, creating a python4 without calling it so. That's the unfortunate modern trend. The web folks that move fast and break things love living on the bleeding edge, and create strong pressure for everyone to keep up, and that the answer to library compatibility is "wait until someone complains, fix the direct reason, cut a new release, and let the dependents fix their own code".
  - scrollaway 2y ago
    > They claim "nobody is maintaining them"… but they are well funded and can easily afford someone to maintain them. You still have to find someone who both wants and can maintain them. That's not always a given. And also, why? If I donate to the PSF, do I really want my money to go into the maintenance of ... checks notes ... MacOS 9 path manipulation functions (https://docs.python.org/it/3.7/library/macpath.html https://docs.python.org/it/3.7/library/macpath.html)? Just because you're well-funded doesn't mean you get to spend money on useless things. And most of the python community would consider this useless. Nobody even made a pypi copy of it.
killingtime74 2y ago
“640K ought to be enough for anybody.” Bill Gates on RAM (he didn't really say it apparently).
- RandomThoughts3 2y ago
  I’m sorry, I’m not sure how the quote is relevant to the comment you are replying. Mature languages don’t tend to break working code. That was true when the quote was pronounced and that’s still true today. Python is fairly unique in its propensity to be an unstable target. I personally can only think of the JS ecosystem has being worse but even then that’s mostly a library thing as the VM will run even the oldest JS code you can find. I wish the same could be said of Python.
  - zo1 2y ago
    I honestly don't know where this "python is brittle" comes from. I've been using python heavily since the 2.5 days, and I can count on maybe 2 hands the times I've had a library or dependency break on me. Most of those were due to weird library function signature changes, that type-hints have now arguably fixed anyways.
    - aragilar 2y ago
      I avoid type hints (and instead use other linters/static analysis tools like pylint) because type hints break between Python versions...
    - RandomThoughts3 2y ago
      > I honestly don't know where this "python is brittle" comes from. From Python being brittle? It’s one of the rare language which deprecates and removes API between minor versions. They have to provide migration guides with every release.
      - KaiserPro 2y ago
        can you give an example? I'm struggling to find an example of something removed in a minor version.
deleted 2y ago
[deleted]
aswerty 2y ago
As somebody who welcomes killing off the GIL. I would agree that Python is changing too much. It seems to be in this constant state of flux starting from around the Python 2 to 3 era (though maybe it was always like this and I wasn't familiar enough with it to know how it was before that). While all languages change, Pythons changes seem to be existential in nature. For such a long lived language to have this much immaturity is worrying. I guess the side affect of such popularity later in life.
- mnky9800n 2y ago
  I think partly to blame is the people who refused to move to 3.x. I remember in 2016-17 I worked on a new project and people say and argued that we simply had to use 2.x and that it would never go away. There wasn't even 2.x dependencies for the project. And I feel like that kind of mentality really slowed down migration and ultimately helped to create a culture that python would always be changing.
  - rich_sasha 2y ago
    It's an interesting point, both the argument it makes and the background. I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerous and totally unnecessary minor syntax changes (print -> function, map and filter becoming lazy, str/unicode etc) with no major benefits in the upgrade for my use case (data science), other than compatibility. Some of the new syntax was neither bad or good (what's so wrong with print being a statement? Add a printfn function if you really want one), some were IMHO outright bad (map and filter becoming lazy, reduce being kicked out to a module), str->unicode was maybe the only good one, but even that is controversial. The deliberate neutering of `bytes` was unnecessary too. Python 3 brought various implementation improvements and nice new syntax, which could have been implemented in a Python 2 syntax too (dict and set comprehensions for example) So I saw no reason why Python 3 couldn't in fact be syntactically compatible with 2, and saw the whole thing as a bit of an upgrade circus: wanna keep using the language? Make these arbitrary changes because someone thought print ought to be a function. You could argue it was the same disregard for stability as the now many versions of Python 3.
graemep 2y ago
> I get that for people for whom Python is their main language, all these changes make their lives better Python is my main language and backward compatibility is far more important to me than performance. Almost everything I do spends most of its time waiting for IO, or in a C library, or another process, or performance is unimportant. That is why Python is my main language. I think it is possible that Python's popularity with people doing numerical stuff might end up making it worse for the rest of us.
- sigmoid10 2y ago
  >I think it is possible that Python's popularity with people doing numerical stuff might end up making it worse for the rest of us. I've been using Python since long before it became the go-to choice for numerics inside and outside academia, so let me tell you: It was even worse back then. The transition from 2.7 to 3.0 was both regarding the fundamental idea and the implementation the worst thing I have ever seen happen in any major language. This could (maybe should) have been a language killer. They should have just branched it out as something completely new. Van Rossum is totally right in saying that he never wants a Python 4 for that reason, so it seems at least he learned a little bit since then.
  - mort96 2y ago
    It is only in the past few years that the 2 -> 3 transition stopped hurting for me personally. A lot of Google's Python build system code (which I used to build e.g WebRTC and Chromium) got transitioned to work with Python 3 relatively quickly, HOWEVER it still assumed to be able to execute a Python interpreter by invoking the `python` command. It would work regardless of whether this python interpreter was 2 or 3, but it had python scripts running `python path/to/script.py` using `subprocess`. As systems started shipping Python 3, the convention among most of them became to leave `python` as a Python 2 interpreter and then introduce `python3` as a Python 3 interpreter. As they then stopped shipping Python 2, they generally just removed /usr/bin/python, so the only Python on the system was /usr/bin/python3. In my own scripts to build Google stuff, I always had to make a folder with a single script called `python` which would contain just `exec python3 "$@"`, and then prepend that directory to the `PATH` when invoking Google's tools. Google eventually did update their stuff to work on systems where the only Python is `python3`, but man this transition was rough. As I understand it, Google had good reason to do it their way at the time too; there was simply no consistency in how systems handled the 2 -> 3 switch. I suspect that this is due to a severe lack of guidance from the Python foundation.
m463 2y ago
oh foo. I wrote some python programs that did multithreading, but they didn't work and I had to go elsewhere. So... it is possible you won't find many people in your sample that disagree because the folks that went elsewhere... aren't part of the sample.
mikl 2y ago
> Stop breaking my builds. You don’t have to install the latest version if you don’t want to. If you use a version manager, you can keep using whatever version you want for many years.
- mort96 2y ago
  The value of Python is its ubiquity. That disappears if you have to make sure to install old Python versions because the system Python got updated and the update broke something.
  - rsanek 2y ago
    most tutorials I'm aware of actively discourage use of the system python version for this very case. i don't think it's too surprising that versions differ. there are good tools to manage the python version used -- i personally like pyenv.
    - mort96 2y ago
      This is the exact problem I have. No bash scripting tutorial would tell you to not use your system bash. No perl tutorial would tell you to avoid your system perl. No C tutorial would discourage using your system's gcc or clang. As I said, a lot of the value I see in python is in its ubiquity. This disappears if you can't use the system python.
      - imtringued 2y ago
        You can just use rye and retain your sanity like everyone else.
        mort96 2y ago
        As I said, a lot of the value I see in python is in its ubiquity. I don't understand why I need to keep repeating this.
      - 2y ago

by mort96 2y ago

Elucalidavah 2y ago

> The one big problem it has is that it keeps changing What prevents you from using an old Python version?

dijit 2y ago
Usually us plebs use the system python. With no python version manager (I don’t even know any off the top of my head). Also virtualenvs only get you so far, I’ve come back to many projects on my machine with broken virtualenvs, I guess due to some dynamically linked dependency of python that my system no longer has. :(
- ok_dad 2y ago
  > With no python version manager (I don’t even know any off the top of my head) Try a tool called `pyenv`. It's pretty great. I pair it with the package manager called `poetry`.
  - Joeboy 2y ago
    Or https://github.com/astral-sh/uv https://github.com/astral-sh/uv can replace both. Various features are tagged as "experimental", and I guess the api might change, but it seems to work already. I have high hopes for it eventually making python's fragmented package management issues go away. Edit: Somebody's going to respond with the XKCD aren't they? I know about the XKCD and I nevertheless have high hopes for `uv`.
  - Izkata 2y ago
    Looks like pyenv does the same thing as asdf, except only for python. https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf And here's a list of everything it supports: https://github.com/asdf-vm/asdf-plugins/tree/master/plugins https://github.com/asdf-vm/asdf-plugins/tree/master/plugins
- jashmatthews 2y ago
  It's the sledgehammer approach but... Docker?
  - mort96 2y ago
    Using Docker in order to avoid ever updating Python sounds like a great way to end up in severe tech debt tbh
    - p_l 2y ago
      Arguably it was also non-trivial part of why some places started using Docker...
wakawaka28 2y ago
Using an old Python version means you're stuck using libraries that work with that version. I think you have to figure out which ones work on your own as well.
- scrollaway 2y ago
  Because libraries also change, for the same reason as python changes: To keep up with compatibility of newer devices, systems, and usage patterns. Beside, "figure out which ones work" is a solved issue with a package manager such as poetry.
  - rowanG077 2y ago
    That is if all libraries were super stringent in their dependency bounds. Which in my experience no one is. So it's a crapshoot if it will work or not.
    - SOLAR_FIELDS 2y ago
      This is more of an indictment on how bad Python is about mixing system level packages with library dependencies than anything else. The classic example I always give is psycopg2 depending on a system install of Postgres client library.
      - imtringued 2y ago
        The irritating thing about python is that since it is mostly glue around C, all the annoying things about C leak through.
  - wakawaka28 2y ago
    It's not a solved issue, as others have pointed out. To elaborate, most packages are not maintained continuously. Some don't get updates anymore and some get updates that break older versions of Python. The authors of these libraries definitely aren't rooting out all the problems that can occur due to mismatched versions. And when you change one library, any other related library can be affected. It's like solving a puzzle sometimes. In many cases people throw up their hands and say "forget this, I'm not upgrading anything!" This is also the big driver of solutions like virtualenv and Docker. All languages have this issue to some extent but Python breaks stuff more often than anything else I use. I don't especially like language-specific package downloaders either but that's not a Python-only problem, and there are tradeoffs to pushing the work downstream into more stable systems.
CJefferson 2y ago
I'd love to stick with python 2.7 forever, but it isn't getting even minor updates just to keep up to date with operating system updates, and is starting to stop being packaged. My current solution is a docker container which includes python 2.7 and a downloaded copy of every package I use.
- etrautmann 2y ago
  What do you prefer about it?
  - nlitened 2y ago
    That it has a lot of my old code working perfectly for years, and I don't have spare time to port it to another language and keep catching subtle bugs for months.
    - rglullis 2y ago
      Out of curiosity, how many lines of code are we talking about here?
    - imtringued 2y ago
      "Port it to another language". You're saying this as if the minor asinine breaks in python 2 Vs 3 make it a whole new programming language, when in reality it is mostly bullshit like print going from statement to function.
      - CJefferson 2y ago
        My problem is some libraries which never transitioned from 2 to 3. I don't want to try to convert them, particularly as they involve Unicode which is one of the hardest bits to get right in my experience.
        skeledrew 2y ago
        Improved unicode (string vs byte separation) handling was exactly one of the larger reasons for the breaking change to 3.
guappa 2y ago
> What prevents you from using an old Python version? I think the fact that it's not on the distributions is a major factor here.
mort96 2y ago
Being able to use the system's Python (or in the case of macOS, Homebrew's Python) is extremely convenient. Especially when Python is used as a language for build scripts across a team. I'm not interested in forking Python taking on the responsibility of maintaining, packaging and distributing Python across a range of platforms.

scrollaway 2y ago

This reads a bit like "My neighbourhood is already perfect, I wish it would stop changing". Except as a sibling pointed out, you can live in your old unchanging neighbourhood just fine, you don't have to update it. Python changes because of three reasons: Addressing bugs and insecure patterns; support for new usage patterns in the community; updates for compatibility with newer devices and systems. The first one is a given. The second and third are basically "the world is evolving, with or without you". Even if you built a VM on your perfect machine, with your perfect python and perfect libraries and froze everything for 10 years, the moment you connected it to the internet you'd be faced with "Ah, my perfect version does not support this new thingamajig being used on the web". Freezing everything in time is just archiving.

guappa 2y ago
> Freezing everything in time is just archiving. None of this explains why python has the need to drop modules for the standard library. They claim "nobody is maintaining them"… but they are well funded and can easily afford someone to maintain them. I think at the core they don't care about backwards compatibility, but instead of doing it all at once like with python2/3 are now doing it little by little, creating a python4 without calling it so.
- TeMPOraL 2y ago
  > now doing it little by little, creating a python4 without calling it so. That's the unfortunate modern trend. The web folks that move fast and break things love living on the bleeding edge, and create strong pressure for everyone to keep up, and that the answer to library compatibility is "wait until someone complains, fix the direct reason, cut a new release, and let the dependents fix their own code".
- scrollaway 2y ago
  > They claim "nobody is maintaining them"… but they are well funded and can easily afford someone to maintain them. You still have to find someone who both wants and can maintain them. That's not always a given. And also, why? If I donate to the PSF, do I really want my money to go into the maintenance of ... checks notes ... MacOS 9 path manipulation functions (https://docs.python.org/it/3.7/library/macpath.html https://docs.python.org/it/3.7/library/macpath.html)? Just because you're well-funded doesn't mean you get to spend money on useless things. And most of the python community would consider this useless. Nobody even made a pypi copy of it.

killingtime74 2y ago

“640K ought to be enough for anybody.” Bill Gates on RAM (he didn't really say it apparently).

RandomThoughts3 2y ago
I’m sorry, I’m not sure how the quote is relevant to the comment you are replying. Mature languages don’t tend to break working code. That was true when the quote was pronounced and that’s still true today. Python is fairly unique in its propensity to be an unstable target. I personally can only think of the JS ecosystem has being worse but even then that’s mostly a library thing as the VM will run even the oldest JS code you can find. I wish the same could be said of Python.
- zo1 2y ago
  I honestly don't know where this "python is brittle" comes from. I've been using python heavily since the 2.5 days, and I can count on maybe 2 hands the times I've had a library or dependency break on me. Most of those were due to weird library function signature changes, that type-hints have now arguably fixed anyways.
  - aragilar 2y ago
    I avoid type hints (and instead use other linters/static analysis tools like pylint) because type hints break between Python versions...
  - RandomThoughts3 2y ago
    > I honestly don't know where this "python is brittle" comes from. From Python being brittle? It’s one of the rare language which deprecates and removes API between minor versions. They have to provide migration guides with every release.
    - KaiserPro 2y ago
      can you give an example? I'm struggling to find an example of something removed in a minor version.

deleted 2y ago

[deleted]

aswerty 2y ago

As somebody who welcomes killing off the GIL. I would agree that Python is changing too much. It seems to be in this constant state of flux starting from around the Python 2 to 3 era (though maybe it was always like this and I wasn't familiar enough with it to know how it was before that). While all languages change, Pythons changes seem to be existential in nature. For such a long lived language to have this much immaturity is worrying. I guess the side affect of such popularity later in life.

mnky9800n 2y ago
I think partly to blame is the people who refused to move to 3.x. I remember in 2016-17 I worked on a new project and people say and argued that we simply had to use 2.x and that it would never go away. There wasn't even 2.x dependencies for the project. And I feel like that kind of mentality really slowed down migration and ultimately helped to create a culture that python would always be changing.
- rich_sasha 2y ago
  It's an interesting point, both the argument it makes and the background. I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerous and totally unnecessary minor syntax changes (print -> function, map and filter becoming lazy, str/unicode etc) with no major benefits in the upgrade for my use case (data science), other than compatibility. Some of the new syntax was neither bad or good (what's so wrong with print being a statement? Add a printfn function if you really want one), some were IMHO outright bad (map and filter becoming lazy, reduce being kicked out to a module), str->unicode was maybe the only good one, but even that is controversial. The deliberate neutering of `bytes` was unnecessary too. Python 3 brought various implementation improvements and nice new syntax, which could have been implemented in a Python 2 syntax too (dict and set comprehensions for example) So I saw no reason why Python 3 couldn't in fact be syntactically compatible with 2, and saw the whole thing as a bit of an upgrade circus: wanna keep using the language? Make these arbitrary changes because someone thought print ought to be a function. You could argue it was the same disregard for stability as the now many versions of Python 3.

graemep 2y ago

> I get that for people for whom Python is their main language, all these changes make their lives better Python is my main language and backward compatibility is far more important to me than performance. Almost everything I do spends most of its time waiting for IO, or in a C library, or another process, or performance is unimportant. That is why Python is my main language. I think it is possible that Python's popularity with people doing numerical stuff might end up making it worse for the rest of us.

sigmoid10 2y ago
>I think it is possible that Python's popularity with people doing numerical stuff might end up making it worse for the rest of us. I've been using Python since long before it became the go-to choice for numerics inside and outside academia, so let me tell you: It was even worse back then. The transition from 2.7 to 3.0 was both regarding the fundamental idea and the implementation the worst thing I have ever seen happen in any major language. This could (maybe should) have been a language killer. They should have just branched it out as something completely new. Van Rossum is totally right in saying that he never wants a Python 4 for that reason, so it seems at least he learned a little bit since then.
- mort96 2y ago
  It is only in the past few years that the 2 -> 3 transition stopped hurting for me personally. A lot of Google's Python build system code (which I used to build e.g WebRTC and Chromium) got transitioned to work with Python 3 relatively quickly, HOWEVER it still assumed to be able to execute a Python interpreter by invoking the `python` command. It would work regardless of whether this python interpreter was 2 or 3, but it had python scripts running `python path/to/script.py` using `subprocess`. As systems started shipping Python 3, the convention among most of them became to leave `python` as a Python 2 interpreter and then introduce `python3` as a Python 3 interpreter. As they then stopped shipping Python 2, they generally just removed /usr/bin/python, so the only Python on the system was /usr/bin/python3. In my own scripts to build Google stuff, I always had to make a folder with a single script called `python` which would contain just `exec python3 "$@"`, and then prepend that directory to the `PATH` when invoking Google's tools. Google eventually did update their stuff to work on systems where the only Python is `python3`, but man this transition was rough. As I understand it, Google had good reason to do it their way at the time too; there was simply no consistency in how systems handled the 2 -> 3 switch. I suspect that this is due to a severe lack of guidance from the Python foundation.

m463 2y ago

oh foo. I wrote some python programs that did multithreading, but they didn't work and I had to go elsewhere. So... it is possible you won't find many people in your sample that disagree because the folks that went elsewhere... aren't part of the sample.

mikl 2y ago

> Stop breaking my builds. You don’t have to install the latest version if you don’t want to. If you use a version manager, you can keep using whatever version you want for many years.

mort96 2y ago
The value of Python is its ubiquity. That disappears if you have to make sure to install old Python versions because the system Python got updated and the update broke something.
- rsanek 2y ago
  most tutorials I'm aware of actively discourage use of the system python version for this very case. i don't think it's too surprising that versions differ. there are good tools to manage the python version used -- i personally like pyenv.
  - mort96 2y ago
    This is the exact problem I have. No bash scripting tutorial would tell you to not use your system bash. No perl tutorial would tell you to avoid your system perl. No C tutorial would discourage using your system's gcc or clang. As I said, a lot of the value I see in python is in its ubiquity. This disappears if you can't use the system python.
    - imtringued 2y ago
      You can just use rye and retain your sanity like everyone else.
      - mort96 2y ago
        As I said, a lot of the value I see in python is in its ubiquity. I don't understand why I need to keep repeating this.
    - 2y ago