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.

Avoid writing huge, long rambling comments and try to simplify your arguments to less than 100 words. You may find the fault, and the fix, becomes obvious.

Start with trying to refute "The python2 executable still functions correctly as does all other code you have that relies on python2" without referencing anything specific to your build practices.

> 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.

Those where the first that came to mind. There are many others, and many more if you widen it to server-side JS.

If you don't want to read the comment, then also don't bother responding. The comment is long because I am explaining a death by a thousand paper cuts situation. Don't worry, Python isn't going to die just because I don't like it. You don't have to defend Python even if you don't feel like reading my comment. You can also just ignore it or come back to it when you have time to engage with it thoughtfully, instead of just asserting you are correct and having your only argument be that I can't fit my argument to the arbitrary word length you've come up with.

> Those where the first that came to mind. There are many others, and many more if you widen it to server-side JS.

You should stick to talking about Python. This is just not the case and not the culture of browser JS. It's honestly fairly disrespectful of the monumental work browser engineers have done to make that a reality. If you want to switch your argument to server-side JS (where blink and alert don't exist and you are thus leaving it completely as an exercise to the reader to come up with the similar situation), fine, but node 0.10 runs exactly the same today as it did 10 years ago. Again, the bar I am setting is low: have the unchanged thing still gettable and still runnable. I get it. When you work in a certain environment, you imagine all the problems it has must be common and all the benefits are unique. But that isn't the case with this particular problem.

Start with trying to refute "The python2 executable still functions correctly as does all other code you have that relies on python2" without referencing anything specific to your build practices.

Presumably you’re too “not caring about any of this” to just pin your image to “alpine:3.15” and have it just work exactly as before? And presumably you’re too not bothered with any of this to understand that you had to do this because you didn’t pin the image to begin with, so your builds are not reproducible?

And this is anyone else’s problem why?

My point has always been simple: Python causes more pain than other languages when you're not directly using it. I can get node 0.10 on alpine 3.17 just fine. This demonstrates that your comparisons to server JS are completely wrong. But I know, you're going to tell me this is my problem and I expect the world to do work for me or something. Nope. As I've repeatedly stated, I've taken the time to get it to work already. I know you want to believe I'm here waiting for you to fix it, but I'm not. All I've said is: "Huh, I don't have this problem with anything else. I'll keep that in mind before I decide to use stuff from this ecosystem in the future".

The argument I’m making is none of your issues stem from Python specifically. As others have said, you are conflating your own confusion and unwillingness to understand with systemic toolchain issues that do exist. Except, you are not being bitten by those - you’re still at the “shoot myself in the foot and blame the gun” stage.

What a slight of hand to say "You can get it the same way you can with node, except for you can't". You should go into politics. Anyways, you asked me for a simple example, I gave it, and now you want to say what I want doesn't count because "no one wants it". Just choose a different challenge next time.

> thus you’re complaining that nobody else is maintaining this port for you.

I'm just pointing out a discrepancy with other environments. One you initially denied existed, and once I trivially pointed out did exist, you switched to attacking the complaint itself. Look, if I'm looking at two toasters and one has less features, sure, you can bark at me and tell me to make my own toaster if I want that so bad. OK, sure. Or I'll just get the one that has the features I want. You are still allowed to believe that those features are useless, but you can't deny they exist. It is OK for you to disagree with the properties I value in an ecosystem, you don't have to resort to telling me I don't know what I'm doing just because I value a different set of properties in the ecosystem.

Someone has glued on a big red alarm clock onto the side of one of the toasters.

Your conclusion after seeing this is to write to the manufacturer of the toaster without the alarm clock glued onto it and complain that it’s lacking a big red alarm clock and say they suck because they are not copying the amazing alarm clock features that the other manufacturer has.

Ok.

Nobody is threatened by anything, and my point has nothing to do with Python.

If someone posts a comment saying “curl sucks! Every time I run it it just prints ‘command not found’” I’d of course try to tell them that’s not a fault with curl.

If they replied with “yes it is because I can’t figure out how to install it from this 3rd party site” then the discussion may become protected.

But ok, maybe we will agree to disagree.

Afterwards you’d get involved in a long weird analogy discussion about two people arguing about git. But that fault would be shared by both of them.

Python is basically in the same situation as Perl was a decade ago, with the added benefit of mainstream, living-breathing "success stories" like all the data science stuff (numpy, scikit-learn, etc), django, etc. (And Python seems to have a sufficiently large batch of pragmatic & progressive experiments that address various challenges facing users. Decades of effort went into scraping off the warts in areas like packaging, performance, stdlib ergonomics, etc. Python also successfully reformed its leadership.)