11 ms·

As someone who does not use Python, the end result of this is that I now look into whether random utilities I use happen to be written in Python, and if so try

As someone who does not use Python, the end result of this is that I now look into whether random utilities I use happen to be written in Python, and if so try to find an alternative. This is because I felt the pain of this transition -- again, as someone who does not program in Python. It has been miserable every time some random utility starts complaining that Python 3 is missing and then somehow when you install it something else that wants Python 2 starts complaining. You have containers that have worked for years that all of a sudden error out saying "Python 2 is no longer supported," and you have to dig up whatever library or utility that would otherwise work fine has some sort of date-based check or something? I don't know, all I know is a compiled C++ thing works the same yesterday as it does today, and I can upgrade on my timeline, not have a random Docker layer cache invalidation result in a week's worth of Python 3 migration in the least important part of my build. And it keeps happening, again, because this is not in stuff I directly edit, it's all in random dependencies and sub-utilities of utilities I install. So it is non-trivial to even go in with the mindset of "I will update everything on our systems that use Python". Although I guess if it's being pulled completely now that job will once again be done for me. Sigh. I have this opinion about no other language. I am generally neutral about languages I don't use. But literally my only experience with Python is porting to Python 3. It's like a sitcom scenario of how to force the worst possible first impression for a language ever. The amount of slowdown and pain that Python 3 has generated on our non-Python project is really just out of this world ridiculous.

Apofis 4y ago
I just avoid Python and any job descriptions that contain it. It's never been a good experience for me, whether as an end user or a developer. It's nice that they may have ironed out their issues, but I've been done a long time ago. There's nothing Python does I can't do better with some other toolchain.
Waterluvian 4y ago
I’m curious why installing Python 3 causes Python 2 programs to break. The only reason I can come up with is that the installation process is wrongly changing the `Python` symlink. Anyone have other known causes? Does it screw with dependencies?
- tolmasky 4y ago
  It is hard to keep track of the (no joke) dozens of different weird failures each unique instance of this caused. But I do vaguely recall that sometimes, yes, you now have to go and point each individual utility at the right Python, or set an environment variable, or something. Other times you are relying on some combined build package, which if you want the one that has Python 3, no longer includes Python 2. So then you have to go manually install it. But it's no longer provided as an independent install by that package manager anymore, it was just a coincidence that it was still being included in buildpacks-whatever, so now you have to decide whether you want to figure out how to find and install Python 2 yourself or maybe just go and update everything else to Python 3 too or... UGH. Then you remember "Wait a minute, why I am I doing this, I'm not even a Python programmer!" The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too, so all of a sudden updating something to the Python 3 version means that all of its associated config files have changed format, and now you're updating config files that have worked great for ages and running into bugs there.
  - happymellon 4y ago
    > The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too Your issue with Python is that some people having bad development practices?
    - tolmasky 4y ago
      That was one issue I mentioned. You know that. You read my comments. However, I will take your snarky reply and turn it into lemonade by using it as an opportunity to talk about how often development teams fail to consider the social implications of their changes. As is mentioned in another comment on this post, the Python team seems to readily admit in retrospect that they didn't predict the pain of having no clear transition path, etc. I think another lesson to take from this experience is the realization that if you create some big "line in the sand" update, you may absolutely inadvertently encourage bad development practices. If the Python 2-to-3 transition had held "ease of transition" as a core value, then it is more likely that that value would have been modeled downstream. By instead initially declaring that the 2-to-3 transition was going to be some watershed moment and people were going to have to update everything, it is not surprising that it could encourage people to just pull the trigger on a bunch of breaking stuff they wanted to do, and come to the (incorrect, but understandable) conclusion that they didn't themselves need backwards compatibility since the entire ecosystem was going through a "unique" non-backwards-compatible change anyways.
leephillips 4y ago
I agree completely, plus there are all the conflicting ways of installing and managing Python programs, dependencies, and environments, and the poor quality of so much Python code, some of it widely used. I find myself having to switch the `python` symlink in my path between python2 and python3 regularly, I look forward to the day when I can purge my systems of all traces of Python.
- wildrhythms 4y ago
  The number of times I find a script that blindly assumes 'python' points to its required version is too damn high. It makes me question the general competency of the people shipping Python code.
  - leephillips 4y ago
    It’s inexcusable in recent scripts, but some of these date from the time when there was only python2. No, the root of the problem, as pointed out by many others here, is the policy decision to create two incompatible interpreters both called “python”.
    - jeroenhd 4y ago
      I think it's actually more excusable in recent scripts as Python 2.7 has been deprecated and unsupported for ages now. You won't know what version of Python 3 you're getting, but at this point it's safe to assume you're getting a version of Python 3 when you call python. Only old scripts written when Python 2 and 3 were maintained separately should've ever had this problem, but we're past that point now.
      - bloblaw 4y ago
        Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that. How about one with dataclasses support? Again, you get to install a new interpreter everywhere. Python packaging continues to be a sore spot for the language.
iforgotpassword 4y ago
I wouldn't avoid a python program right from the start, but simply not bother if it actually wants 2 and only then start looking for an alternative. If anything that debian move might accelerate deprecation or upgrades of stuff that still uses 2. And then we might live in a perfect world with only python 3, because uuuuuunicooooode.
SOLAR_FIELDS 4y ago
This rant feels like it would have been relevant in 2016-2018 or so, but in 2022-2023 I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. Once Python 2 officially EOL’ed the ecosystem basically managed to port whatever was important enough to keep using over to Python 3. Im sure some legacy megacorps are still doing stuff in Python 2 but that’s no different from these corps running some ancient version of Java which is also somewhat common.
- tolmasky 4y ago
  > I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.
  - jasonmp85 4y ago
    The point is just you don’t understand how your tools work.
    - mikewarot 4y ago
      It seems the actual problem is a disagreement on how tools SHOULD work. A saw still works after a decade on a shelf, programs should still work too because they are tools.
Wronnay 4y ago
This is not just a Python problem. I remember when PHP shifted from 5.6 to 7 - I used many projects and software which needed to be updated because e.g. all the mysql_ functions and some crypto functions were removed. Same Issue with e.g. converting Vue 2 to Vue 3 or Angular.js (Version 1) and Angular (Version 2). I really hate when some programming languages or frameworks completely remove important functions which were used by nearly every project.
purkka 4y ago
>You have containers that have worked for years that all of a sudden error out saying "Python 2 is no longer supported," Isn't this precisely the problem containers are trying to solve? You can update your system, get rid of unsupported software, and still keep the older version of Debian within your container that depends on an unsupported version of Python.
- fest 4y ago
  I have noticed pip warnings in the container build logs about python2 being unsupported- perhaps there is some "treat warnings as errors" flag set in some builds. Perhaps some builds use untagged base OS containers- building those after python2 is removed will fail. Also, at some point old OS package repositories may be deleted (or bitrot out of neglect)- at that point building containers that depend on python2 will fail. You'll be able to use images built previously, but not everyone is backing up custom images in some remote docker registry.
- tolmasky 4y ago
  That's the dream of containers. Arguably this is the "reality" of Nix. But the reality of containers is that if a layer gets invalidated, you need to refetch packages that are lower down. If the Python 2 versions (or Python 2 itself) is removed, then you can't "just" surgically make the change you want in the container without affecting the rest of the system (this is a major failing of Docker, but the world we live in). Now, you can start digging around in the container image and trying to do "layer surgery" yourself by editing the tars, but I would also consider that a less than ideal outcome of these changes.
  - edaemon 4y ago
    How would Python 2 end up removed from a container image?
    - sheenobu 4y ago
      If someone builds a container that is designed like this: FROM debian RUN do-x RUN install python2 and then someone changes do-x, if I understand, the layers below it get invalidated and all of a sudden install python2 fails. This is very bad design but very easy to replicate.
bravetraveler 4y ago
It sounds like you do use Python, but when you do, you face this problem... That's fine, but I wanted to clarify - you intend to not use Python, because you have tried and it's not gone well. Python didn't come out of the woodwork and attack you, so much as you stepped into a (momentarily) troubled ecosystem. I understand they were dependencies of other projects. By using those, they became your dependencies. Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Distributions do a decent job distributing modules... Utilities have an annoying tendency to rely on SomeStableModule==SpecificVersionForNoReason. This compounds the mess, sadly. Those should be routinely addressed as part of your auditing, along with the whole of the supply chain I can't really prescribe much... this is just generic advice. I understand the woes, it's just not as unique as this is painted
- bloblaw 4y ago
  > Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Huh? This has a strong "No, it's the children who are wrong" vibe. But to be more fair to your point, I think this is a dismissal of the OP concern's. A troubled ecosystem should be concerning to the Python community as a whole because it threatens future adoption if not addressed. User's don't want a troubled ecosystem and will find languages that avoid these problems...and Go, Nim, and to smaller extent Zig, Rust, D are strong alternatives for the different workloads currently provided by Python tooling. Python has a good moat with both ML and mind-share of developers...but at one time Perl had a similar moat...
  - bravetraveler 4y ago
    It's a fair criticism, I know it's a bit harsh! I appreciate it and both the more fair take. > User's don't want a troubled ecosystem and will find languages that avoid these problems It's true, I'm very late to Python myself -- for the exact same reason. The distribution part of the ecosystem is a nightmare. People want utilities, but they learn more than they ever cared to because of dependencies. I'm only learning how to manage it now because work demands it. Prior, all of my needs had fortunately been met by my Linux distribution of choice -- the Python part was abstracted away, for the most part. Developers of these utilities could save some (shared) effort by offering package specs/finding a maintainer, but I understand why it's not common. (I may even build/maintain it for you, to sweeten the pot) I guess the fuel of this thing is, 'misery loves company' -- I'm dealing with it, and I can't just whine about it. The "I don't use it and it still affects me part" was the bait -- they do use it
orf 4y ago
The python2 executable still functions correctly as does all other code you have that relies on python2. Make sure the code is in the right place and run the python executable just as you have done before. However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works. If you wish to use something nobody else wants to support, then you need to support it yourself. Otherwise, take a moment to understand the thing you are using and follow any instructions to upgrade. Don't put ignorance on a pedestal and then make the argument that the fruits of your ignorance are only the fault of others and not yourself.
- philistine 4y ago
  alert and blink don't make browsers stop working. They degrade gracefully, just like Pyhton doesn't.
- tolmasky 4y ago
  > However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works. Incorrect. You have to understand that I am not a Python user, and don't a priori care what they do with the language. I only become annoyed when something breaks on its own, or if changing one unrelated thing breaks other unrelated things. This happens for a variety of reasons: 1. Either date-based breaking, or patch releases designed just to throw up deprecations, and breaking the tools you actually use. 2. Packages and or binaries disappearing from package managers, such that even if I have a pinned version and I make no changes, an accidental cache invalidation can now break the entire image. 3. The fact that updating one utility may break others (either because you need to figure out this python symlinking issue or whatever). 4. Python causing discontinuities that don't exist in other bundled build tools. Going from buildpacks:x to buildpacks:y, to get a new feature in A, usually doesn't affect B, but in the specific case of Python, means the installed version might change and break a bunch of stuff. 5. Python 3 changes often being bundled with breaking API changes in app updates, making "upgrading to Python3" a uniquely involved challenge for each one. If you deprioritize "fault" for a second, such that we're not deciding who's to blame here (whether it's the transition plan by the language devs, the library or app authors, the distribution handlers, or even end users like me), you have to reconcile the fact that this is a unique situation to python. I am not describing the woes of development in general. I am describing a very python-specific set of experiences for non-python users. I did not out of nowhere decide to get angry at a language I don't use. This is the result of a repeated set of circumstances that just aren't happening elsewhere. As has been mentioned throughout this thread, it is further upsetting that a lot of this could have been avoided. The fact that there are things that could have been done differently to make the long tail effect less painful is fairly disappointing. At the end of the day, I don't need a list of solutions. I've implemented them all, don't worry. I've gone through and read the 500-thumbs-upped threads of people repeatedly running into this exact same problem, either found an easy workaround or taken the time to update the config files for a tool that rudely put itself at the front of my priorities list in order to fix the build, or found a way to remove the utility in question completely. This is not me coming on here trying to figure out how to move forward. This is me identifying a clear pattern, and sharing what I believe to be is a common conclusion: putting "python" in the "cons" column when considering a tool. I come from the node world. There's plenty of people that do the same for node. Some of it I consider fair, others not. But I make no illusions about one fact: if we want to change that perception, it's up to us to earn that by making the experience better going forward, not by explaining to people why their experience actually isn't real. For example, if there is a simple solution, if you just were familiar with the ecosystem, then LOG IT WHEN THE ERROR HAPPENS. If the person has to go to stack overflow and see a thousand other people running into the same thing, then you've failed. > However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works. This is also hilarious since you had to scrape the bottom of the barrel to find the only instances of "non backwards compatible" features in JS/HTML, an environment notorious for backwards compatibility. Also, `alert` may still stay in.
gauddasa 4y ago
It's ok. At least our children won't have to go through this dreaded dependency hell. Also, the role of Python 3 in popularizing Python was worth all the pain. Without version 3 it would not have been where it stands today.
- dagw 4y ago
  Without version 3 it would not have been where it stands today. I fail to see how that is true. Python was already catching on in a big way back during python 2.7 and I'd guess it probably lost at least 18 month worth of momentum building with python 2->3. I'd say Pythons popularity today is at best unrelated to python 3.
  - pas 4y ago
    Python lost a lot more due to the constant flamewars about the transition, how many people wanted to just not care about py3 for many long years, etc. languages that are actually growing in userbase/popularity are not static. this is hard to accept for many users of popular languages.
still_grokking 4y ago
This is the top comment? In the year 2023? OMG, that's a parody I hope!
lucyferzyr 4y ago
I tried to learn Python around 2008-2009 and it was literally the worst time to try to learn Python, the transition to Python3 was just beginning, take 2 random code samples from the internet and they won't work together, python2to3 didn't work either. It's kind of a shame how this transition took more than 10 years. The good part, we learned that we don't have to go through the same again. of course I dropped python (I was like 18 years old and didn't know anything about programming), I had to learn python last year and you still can see a lot of stuff that makes the experience kind of annoying. Anyway, I'm pretty impressed how Python still is in the first positions of most charts, I still fail to see how great the language is, but hopefully I will be able to someday soon :)

Apofis 4y ago

I just avoid Python and any job descriptions that contain it. It's never been a good experience for me, whether as an end user or a developer. It's nice that they may have ironed out their issues, but I've been done a long time ago. There's nothing Python does I can't do better with some other toolchain.

Waterluvian 4y ago

I’m curious why installing Python 3 causes Python 2 programs to break. The only reason I can come up with is that the installation process is wrongly changing the `Python` symlink. Anyone have other known causes? Does it screw with dependencies?

tolmasky 4y ago
It is hard to keep track of the (no joke) dozens of different weird failures each unique instance of this caused. But I do vaguely recall that sometimes, yes, you now have to go and point each individual utility at the right Python, or set an environment variable, or something. Other times you are relying on some combined build package, which if you want the one that has Python 3, no longer includes Python 2. So then you have to go manually install it. But it's no longer provided as an independent install by that package manager anymore, it was just a coincidence that it was still being included in buildpacks-whatever, so now you have to decide whether you want to figure out how to find and install Python 2 yourself or maybe just go and update everything else to Python 3 too or... UGH. Then you remember "Wait a minute, why I am I doing this, I'm not even a Python programmer!" The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too, so all of a sudden updating something to the Python 3 version means that all of its associated config files have changed format, and now you're updating config files that have worked great for ages and running into bugs there.
- happymellon 4y ago
  > The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too Your issue with Python is that some people having bad development practices?
  - tolmasky 4y ago
    That was one issue I mentioned. You know that. You read my comments. However, I will take your snarky reply and turn it into lemonade by using it as an opportunity to talk about how often development teams fail to consider the social implications of their changes. As is mentioned in another comment on this post, the Python team seems to readily admit in retrospect that they didn't predict the pain of having no clear transition path, etc. I think another lesson to take from this experience is the realization that if you create some big "line in the sand" update, you may absolutely inadvertently encourage bad development practices. If the Python 2-to-3 transition had held "ease of transition" as a core value, then it is more likely that that value would have been modeled downstream. By instead initially declaring that the 2-to-3 transition was going to be some watershed moment and people were going to have to update everything, it is not surprising that it could encourage people to just pull the trigger on a bunch of breaking stuff they wanted to do, and come to the (incorrect, but understandable) conclusion that they didn't themselves need backwards compatibility since the entire ecosystem was going through a "unique" non-backwards-compatible change anyways.

leephillips 4y ago

I agree completely, plus there are all the conflicting ways of installing and managing Python programs, dependencies, and environments, and the poor quality of so much Python code, some of it widely used. I find myself having to switch the `python` symlink in my path between python2 and python3 regularly, I look forward to the day when I can purge my systems of all traces of Python.

wildrhythms 4y ago
The number of times I find a script that blindly assumes 'python' points to its required version is too damn high. It makes me question the general competency of the people shipping Python code.
- leephillips 4y ago
  It’s inexcusable in recent scripts, but some of these date from the time when there was only python2. No, the root of the problem, as pointed out by many others here, is the policy decision to create two incompatible interpreters both called “python”.
  - jeroenhd 4y ago
    I think it's actually more excusable in recent scripts as Python 2.7 has been deprecated and unsupported for ages now. You won't know what version of Python 3 you're getting, but at this point it's safe to assume you're getting a version of Python 3 when you call python. Only old scripts written when Python 2 and 3 were maintained separately should've ever had this problem, but we're past that point now.
    - bloblaw 4y ago
      Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that. How about one with dataclasses support? Again, you get to install a new interpreter everywhere. Python packaging continues to be a sore spot for the language.

iforgotpassword 4y ago

I wouldn't avoid a python program right from the start, but simply not bother if it actually wants 2 and only then start looking for an alternative. If anything that debian move might accelerate deprecation or upgrades of stuff that still uses 2. And then we might live in a perfect world with only python 3, because uuuuuunicooooode.

SOLAR_FIELDS 4y ago

This rant feels like it would have been relevant in 2016-2018 or so, but in 2022-2023 I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. Once Python 2 officially EOL’ed the ecosystem basically managed to port whatever was important enough to keep using over to Python 3. Im sure some legacy megacorps are still doing stuff in Python 2 but that’s no different from these corps running some ancient version of Java which is also somewhat common.

tolmasky 4y ago
> I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.
- jasonmp85 4y ago
  The point is just you don’t understand how your tools work.
  - mikewarot 4y ago
    It seems the actual problem is a disagreement on how tools SHOULD work. A saw still works after a decade on a shelf, programs should still work too because they are tools.

Wronnay 4y ago

This is not just a Python problem. I remember when PHP shifted from 5.6 to 7 - I used many projects and software which needed to be updated because e.g. all the mysql_ functions and some crypto functions were removed. Same Issue with e.g. converting Vue 2 to Vue 3 or Angular.js (Version 1) and Angular (Version 2). I really hate when some programming languages or frameworks completely remove important functions which were used by nearly every project.

purkka 4y ago

>You have containers that have worked for years that all of a sudden error out saying "Python 2 is no longer supported," Isn't this precisely the problem containers are trying to solve? You can update your system, get rid of unsupported software, and still keep the older version of Debian within your container that depends on an unsupported version of Python.

fest 4y ago
I have noticed pip warnings in the container build logs about python2 being unsupported- perhaps there is some "treat warnings as errors" flag set in some builds. Perhaps some builds use untagged base OS containers- building those after python2 is removed will fail. Also, at some point old OS package repositories may be deleted (or bitrot out of neglect)- at that point building containers that depend on python2 will fail. You'll be able to use images built previously, but not everyone is backing up custom images in some remote docker registry.
tolmasky 4y ago
That's the dream of containers. Arguably this is the "reality" of Nix. But the reality of containers is that if a layer gets invalidated, you need to refetch packages that are lower down. If the Python 2 versions (or Python 2 itself) is removed, then you can't "just" surgically make the change you want in the container without affecting the rest of the system (this is a major failing of Docker, but the world we live in). Now, you can start digging around in the container image and trying to do "layer surgery" yourself by editing the tars, but I would also consider that a less than ideal outcome of these changes.
- edaemon 4y ago
  How would Python 2 end up removed from a container image?
  - sheenobu 4y ago
    If someone builds a container that is designed like this: FROM debian RUN do-x RUN install python2 and then someone changes do-x, if I understand, the layers below it get invalidated and all of a sudden install python2 fails. This is very bad design but very easy to replicate.

bravetraveler 4y ago

It sounds like you do use Python, but when you do, you face this problem... That's fine, but I wanted to clarify - you intend to not use Python, because you have tried and it's not gone well. Python didn't come out of the woodwork and attack you, so much as you stepped into a (momentarily) troubled ecosystem. I understand they were dependencies of other projects. By using those, they became your dependencies. Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Distributions do a decent job distributing modules... Utilities have an annoying tendency to rely on SomeStableModule==SpecificVersionForNoReason. This compounds the mess, sadly. Those should be routinely addressed as part of your auditing, along with the whole of the supply chain I can't really prescribe much... this is just generic advice. I understand the woes, it's just not as unique as this is painted

bloblaw 4y ago
> Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Huh? This has a strong "No, it's the children who are wrong" vibe. But to be more fair to your point, I think this is a dismissal of the OP concern's. A troubled ecosystem should be concerning to the Python community as a whole because it threatens future adoption if not addressed. User's don't want a troubled ecosystem and will find languages that avoid these problems...and Go, Nim, and to smaller extent Zig, Rust, D are strong alternatives for the different workloads currently provided by Python tooling. Python has a good moat with both ML and mind-share of developers...but at one time Perl had a similar moat...
- bravetraveler 4y ago
  It's a fair criticism, I know it's a bit harsh! I appreciate it and both the more fair take. > User's don't want a troubled ecosystem and will find languages that avoid these problems It's true, I'm very late to Python myself -- for the exact same reason. The distribution part of the ecosystem is a nightmare. People want utilities, but they learn more than they ever cared to because of dependencies. I'm only learning how to manage it now because work demands it. Prior, all of my needs had fortunately been met by my Linux distribution of choice -- the Python part was abstracted away, for the most part. Developers of these utilities could save some (shared) effort by offering package specs/finding a maintainer, but I understand why it's not common. (I may even build/maintain it for you, to sweeten the pot) I guess the fuel of this thing is, 'misery loves company' -- I'm dealing with it, and I can't just whine about it. The "I don't use it and it still affects me part" was the bait -- they do use it

orf 4y ago

The python2 executable still functions correctly as does all other code you have that relies on python2. Make sure the code is in the right place and run the python executable just as you have done before. However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works. If you wish to use something nobody else wants to support, then you need to support it yourself. Otherwise, take a moment to understand the thing you are using and follow any instructions to upgrade. Don't put ignorance on a pedestal and then make the argument that the fruits of your ignorance are only the fault of others and not yourself.

philistine 4y ago
alert and blink don't make browsers stop working. They degrade gracefully, just like Pyhton doesn't.
tolmasky 4y ago
> However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works. Incorrect. You have to understand that I am not a Python user, and don't a priori care what they do with the language. I only become annoyed when something breaks on its own, or if changing one unrelated thing breaks other unrelated things. This happens for a variety of reasons: 1. Either date-based breaking, or patch releases designed just to throw up deprecations, and breaking the tools you actually use. 2. Packages and or binaries disappearing from package managers, such that even if I have a pinned version and I make no changes, an accidental cache invalidation can now break the entire image. 3. The fact that updating one utility may break others (either because you need to figure out this python symlinking issue or whatever). 4. Python causing discontinuities that don't exist in other bundled build tools. Going from buildpacks:x to buildpacks:y, to get a new feature in A, usually doesn't affect B, but in the specific case of Python, means the installed version might change and break a bunch of stuff. 5. Python 3 changes often being bundled with breaking API changes in app updates, making "upgrading to Python3" a uniquely involved challenge for each one. If you deprioritize "fault" for a second, such that we're not deciding who's to blame here (whether it's the transition plan by the language devs, the library or app authors, the distribution handlers, or even end users like me), you have to reconcile the fact that this is a unique situation to python. I am not describing the woes of development in general. I am describing a very python-specific set of experiences for non-python users. I did not out of nowhere decide to get angry at a language I don't use. This is the result of a repeated set of circumstances that just aren't happening elsewhere. As has been mentioned throughout this thread, it is further upsetting that a lot of this could have been avoided. The fact that there are things that could have been done differently to make the long tail effect less painful is fairly disappointing. At the end of the day, I don't need a list of solutions. I've implemented them all, don't worry. I've gone through and read the 500-thumbs-upped threads of people repeatedly running into this exact same problem, either found an easy workaround or taken the time to update the config files for a tool that rudely put itself at the front of my priorities list in order to fix the build, or found a way to remove the utility in question completely. This is not me coming on here trying to figure out how to move forward. This is me identifying a clear pattern, and sharing what I believe to be is a common conclusion: putting "python" in the "cons" column when considering a tool. I come from the node world. There's plenty of people that do the same for node. Some of it I consider fair, others not. But I make no illusions about one fact: if we want to change that perception, it's up to us to earn that by making the experience better going forward, not by explaining to people why their experience actually isn't real. For example, if there is a simple solution, if you just were familiar with the ecosystem, then LOG IT WHEN THE ERROR HAPPENS. If the person has to go to stack overflow and see a thousand other people running into the same thing, then you've failed. > However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works. This is also hilarious since you had to scrape the bottom of the barrel to find the only instances of "non backwards compatible" features in JS/HTML, an environment notorious for backwards compatibility. Also, `alert` may still stay in.

gauddasa 4y ago

It's ok. At least our children won't have to go through this dreaded dependency hell. Also, the role of Python 3 in popularizing Python was worth all the pain. Without version 3 it would not have been where it stands today.

dagw 4y ago
Without version 3 it would not have been where it stands today. I fail to see how that is true. Python was already catching on in a big way back during python 2.7 and I'd guess it probably lost at least 18 month worth of momentum building with python 2->3. I'd say Pythons popularity today is at best unrelated to python 3.
- pas 4y ago
  Python lost a lot more due to the constant flamewars about the transition, how many people wanted to just not care about py3 for many long years, etc. languages that are actually growing in userbase/popularity are not static. this is hard to accept for many users of popular languages.

still_grokking 4y ago

This is the top comment? In the year 2023? OMG, that's a parody I hope!

lucyferzyr 4y ago

I tried to learn Python around 2008-2009 and it was literally the worst time to try to learn Python, the transition to Python3 was just beginning, take 2 random code samples from the internet and they won't work together, python2to3 didn't work either. It's kind of a shame how this transition took more than 10 years. The good part, we learned that we don't have to go through the same again. of course I dropped python (I was like 18 years old and didn't know anything about programming), I had to learn python last year and you still can see a lot of stuff that makes the experience kind of annoying. Anyway, I'm pretty impressed how Python still is in the first positions of most charts, I still fail to see how great the language is, but hopefully I will be able to someday soon :)