Python 2 removed from Debian
bugs.debian.org
bugs.debian.org
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.
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.
A saw still works after a decade on a shelf, programs should still work too because they are tools.
That is, I believe, the entire point of the parent, is it not? That this whole migration was not quarantined to the Python developer community. That it spilled over to users in totally unrelated spaces.
That was it. Since then I use Git everywhere even though I prefer Hg.
I feel your response is best summarized as: "I like Python. I've never had this problem and don't think it's a legitimate problem. Only $megacorp users have this issue, and their concerns aren't important."
If you dismiss the problem (as you've done) then you don't have to intellectually address it. The Python 2 -> 3 transition was hard for those that huge productive workloads in Python2, and this pain will have a long tail.
Whoever missed that is self responsible for all self harm done by ignoring that.
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.
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.
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.)
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.
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.
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.
FROM debian
RUN do-x
RUN install python2
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.
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?
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.
Your issue with Python is that some people having bad development practices?
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.
It was to precisely avoid this scenario where you get it switched out from under you.
This doesn’t mean every distro followed suite (though most popular ones were good about it) , but the biggest issue is users. Tons of users create the symlink or alias for convenience and then forget about it till stuff breaks.
> Distributors may choose to set the behavior of the python
> Avoiding breakage of such third party scripts was the key reason this PEP *used to* recommend that python continue to refer to python2.
Emphasis mine.
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.
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 :)
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.
languages that are actually growing in userbase/popularity are not static. this is hard to accept for many users of popular languages.
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
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...
> 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
Not sure where you're going with this. I didn't whine to someone else to fix it. I did take ownership. Over and over. I fixed these problems, as unrelated to my main goal as they were. I then complained about it after the fact. Seems like a totally fair ordering of events to me.
Separately, I will state that Python is an environment that seems to go out of its way to make it hard to meticulously manage dependencies if you want to. There's all sorts of competing environments and package managers. I'm sure it's straightforward if that's your main environment, but it doesn't help if you're coming form the outside.
> Those should be routinely addressed as part of your auditing, along with the whole of the supply chain
This assumes that the only available option is "manage this dependency better". That's not the only option. There is also "consider using something different that is easier to manage." Most of these utilities exist in a competitive market. And if there are utilities that allow me to choose the cadence and separately make that auditing simpler, then I will choose that. That is the point of my statement. I am not choosing to go on a hunger strike or avoiding some no-other-choice tool. Quite the contrary, a lot of these tools were chosen by other members of the team at some point, either because it's what they were familiar with or some other unimportant reason, and now they have, to their own detriment, made themselves the squeaky wheel, and opened up the range of possibilities to everything from "put in the work to maintain this tool that has currently demonstrated itself to be brittle" to "maybe I should use something else". Generally speaking, it's a bad thing to only draw attention to yourself when you are doing something bad.
> can't really prescribe much... this is just generic advice.
And yet this is a specific problem.
> I understand the woes, it's just not as unique as this is painted
It very much is unique. I'm literally not experiencing this with any other language that I don't directly use. Do I experience this with the libraries I directly use in my language? Of course. I signed up for that. I know the risks I take using beta builds and have a keen sense of the current internal transitions, etc. But I absolutely do not become aware of the latest argument in the C++ language spec, or a contentious Swift proposal, or end up becoming vaguely aware of the string implementation choices of a language I don't use. That is a unique Python thing. The fact of the matter is, Python has (recently? momentarily perhaps?) proven itself to require more maintenance than other tools I use. The community can decide who's at fault for this (language devs, library devs, end users, whatever), and even whether or not it matters, but if the message to the people outside the community is to deny that this is unique or troubling, then don't be surprised if the way they choose to take ownership is to count Python as a point against a project they are considering to use.
It was very knee-jerk to the interpretation that I had: "distance has been kept from Python and yet it's been a problem"
There hasn't been that much distance, truth be told. You did the same care for Python as you did the libraries, but it cost too much.
We're in complete agreement on dependency/manager aspects of Python -- my main point is, that's the core of it, I guess.
Everyone goes through this, it's awful and annoying, and my original post is a poor response to the presentation of that
The Python 2 vs 3 thing is settled, upgrade to a recent LTS and it's done... until a random relic utility comes around. Then obviously discard it
OMG, that's a parody I hope!
Congratulations to Debian on upgrading to Python 3!
And what surprised me most is that every time I mentioned this, there would be lots people telling me how this is a superior design because you can operate string like bytes. I mean, it of course has its upside, but I don't think it's worth it if you care even slightly beyond ASCII.
For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief. Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017.
I'm sure you could do things well in Python 2 with proper combinations of encode/decode, but it wasn't obvious where you even needed those because with ascii text, things "just worked" transparently. With Python 3 it's very obvious where you need encoding/decoding because bytes != str.
The problem is not the end-user invoking the command.
The problem is scrips expecting `#!/usr/bin/env python` to invoke python-2.
apt install python-is-python3
For example GnuRadio started supporting Python 3 with GnuRadio 3.8 released in 2019, and then you had to port all your programs using it to this version. So no, in 2017, the ecosystem was not ready.
In order to support Windows better, Python 3 introduced support for UCS-4 (or worse, UTF-16) strings (depending on a compilation setting when Python was compiled) and they had to introduce extra string types to distinguish readable strings from binary strings ("bytes").
These extra types made Python 3 a lot harder to teach (I teach 30 person classes every year).
So it's not all roses now.
In the end, I got used to it, BUT I just gave up asking encode()/decode() questions at the exams. Very few people understand it, or care enough (and I understand why--it's a ridiculous thing to have). You only need it if your OS somehow slept through the introduction of UTF-8, which is backward compatible with ASCII, resilient even if there are transfer errors and can encode all unicode characters.
Encoding problem used to be really common in UNIX (and before that, in mainframes), but with the introduction of UTF-8, all encoding problems I had vanished and never appeared again.
Even Windows 10 has an UTF-8 mode now and the Windows API functions that end in "A" can be made to use UTF-8.
Now, in a sense, Python 3 has this entire complication for no reason.
That said, Python 3 is ok to use now--and, conceptually, distinguishing byte strings from unicode strings is better (for example so that you don't accidentially print the former to the terminal). It just uses up brain cycles that you could be using for solving your actual problems.
I get it from the "pass the exam" perspective, since that's one more thing to worry about.
But from my experience in teaching others, doing the conversion between bytes and string implicitly (à la Python 2's way) hinders actual understanding of this very important concept, and it's quite harmful in further study.
Bytes should be considered as a separate, more low-evel thing, away from int/float/strings; at the very least, it should be considered as bits/hex numbers. If you want strings, you explicitly encode/decode them in a way, even if everything is UTF-8.
On top of that, "byte string" is just a confusing concept. It might works for English speaker (by "it's a ridiculous thing to have" I assume you mean that, "'english'.encode() is just b'english', why bother?"), not at all for Chinese speakers, even in UTF-8. There is no b'中文' -- only b'\xe4\xb8\xad\xe6\x96\x87' which has zero meanings in their own.
And even from an easy-to-use perspective: most people don't even work on bytes often nowadays. A more abstract "string" type is all they need, without worrying about how it works under the hood (and if they do, they need to understand how encode/decode works properly anyway).
That's not true at all. I remember all kinds of encoding errors when dealing with the FS, the network or any user input when using Linux.
Unless you're talking specifically about IDLE?
Debian had Py3 for ages. It wasn't upgrade, that happened ages ago, just removing old packages kept for compatibility
The print-as-a-statement was ugly but convenient and didn't seem like a big deal, the integer division was something that you could live with once you knew about it (and you still need to know what the current behavior is), and the new string types make code more verbose, and the way they were handled introduced countless hard to find bugs during the migration.
Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013):
The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing.
Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then maybe it would have been. As it stands, Python's biggest weaknesses remain unaddressed.
Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of my time debugging straightforward code was spent chasing down and fixing UnicodeErrors, knowing that some will still remain. And that includes code that used nothing but the standard library.
Now you might think that’s not important, and though I disagree (especially when talking about “most users”) that would be fair. But it is a substantial improvement going from 2 to 3.
That's reading far too much into a tongue in cheek presentation title.
Besides, good devs are typically reasonably skeptical of new and shiny.
And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment.
Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features.
And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.
And, the latest iterations of Python3 have real usability improvements - the error message improvements alone make development a lot nicer. And the perf improvements and jit coming I think in 3.13 will really make more people consider py3 for their new projects.
More like it shows that many people like GP are only aware of the superficial changes.
Also, the fact that there is a talk with such a name does not mean anything other than that someone is out there trying to clarify what the transition is about.
(There could have been a video "Windows 7: Trust me, it's better than Windows XP" and you probably still would say that it showed that improvements aren't worth the switch for most users.)
The first python 3 versions were not great and were missing some things. I think 3.3 didn't even had pip builtin
I ask, because I know I would have wanted that.
use v5.24
The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl.
At the very least they should've just made new one be under .py3 and just make Python3 interpreter transpile Py2 code at runtime
That's terrible practice.
Certainly today DNS domain names, URLs, and email addresses can – and do – contain >0xff input, and for some of these that was the case in 2008 as well (URLs and email addresses – IDN didn't come until a bit later).
The Python 2 situation was untenable and lead to a great many bugs; "decode errors" were something I regularly encountered in Python programs as a user. In hindsight, the migration effort for existing codebases was understated and things could have been done better with greater attention to compatibility, but the problem it addressed was very real.
https://www.w3.org/International/articles/idn-and-iri/
https://www.rfc-editor.org/rfc/rfc6531
etc...
Just because you can get away with ignoring the non english speaking world doesn't mean Python should pretend it can.
At least python3 got that right, unicode by default.
I don't understand why there apparently wasn't a clearly stated preference about `python` being Python 2 and `python3` being Python 3 from the Python org.
Hell, if you're still using 3.6 you're limited in your ability to upgrade dependencies, 3.8 is generally the minimum supported Python version these days.
Most actively maintained Python code works with Python 3 now, but there's still a whole lot of even maintained code which uses `#!/usr/bin/env python`.
Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.
A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example.
The list of stuff that got hard / slow was long. Migration path was unnecessarily difficult as was compatible code. Somewhere around 3.4 it was like a light switch flipped and they started being more reasonable. ASCII handling improved (yes, not all internet protocol stuff is Unicode), they began making it easier to target 2/3 etc. but it was horrible to start. I’ve thankfully forgotten some of the details :)
I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consisted of running 2to3, run tests with python3, and if anything breaked then just touch up the code to get it to work. I know it because I personally ported half a dozen projects throughout the years.
I'll go as far as to claim that most problems porting old python code to 3 were either upstream dependencies dragging their feet or internal human/organizational issues.
Your comment is a perfect illustration of the issues. Lots of user blaming. No actual solution. As I said, it did start to get massively better at some point. Instead of condescending lectures on org issues they for example began allowing u”” in 3, which did not mess up Unicode handling in 3
The other side of that coin is that the python maintainers went out of their way to push back the Python 2 EOL. They kept on pushing the date back and back again, as per the sunset page:
"We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020."
The drawn out demise of Python 2 was, frankly, painful.
I have no time for whinging snowflakes complaining 12 years (2020-2008) was not enough time to migrate their code to Python 3. Hell, even the original 7 years (2015-2008) should have been long enough for 99.999999% of the community.
I'm old enough to have read this when it came out...and it changed my view on backwards compatability (from Joel Spolsky of Trello, FogBugz, and StackOverflow fame)
"Code doesn't rust": https://www.joelonsoftware.com/2000/04/06/things-you-should-...
If a company has production Python2 application / service (with hundreds of thousands of LOC), what business value does it bring to migrate it to Python3?
At that point, if you've got to make severe changes, folks might decide to use a language that doesn't impose breaking changes (and business cost) on them. YMMV.
They had to push back the EOL because they screwed up.
I feel like a lot of the people who had this reaction were reacting to being told (correctly) that how they handled strings was broken. A big reason that projects had difficulty upgrading, especially difficulty using the automatic 2->3 upgrade tooling, was because of broken handling of unicode and broken handling of binary strings. I remember reading a quick assessment of a large open-source project that there were thousands of calls to a single string-handling function that would each need to be inspected by hand to determine whether it was correct usage that would be correctly translated by the 2->3 converter or buggy usage that needed to be fixed before running the 2->3 converter, with some people guessing a 50/50 split. The effort was going to be gargantuan, and though the ultimate cause and responsibility was poor design choices in Python 2, the immediate cause was that the code was wrong, and some people didn't appreciate hearing that.
No one really blamed programmers for getting strings wrong in Python 2. It was unreasonably hard and extremely rare for people to get it right, so there was not really any shame in Python 2 programs and libraries being pervasively broken in that way. But some people still felt it was smug and condescending to make reference to this elephant in the room. This put the Python maintainers in a bad position, because they were trying to explain the benefits of upgrading and also the costs and difficulties, both of which were intimately tied to the brokenness of current codebases.
As a user and spectator to the whole drama, therefore, I felt that some maintainers got overly defensive about issues that virtually every codebase suffered from. And some of them took a "so what" attitude towards bugs involving non-Western languages, saying that if they personally didn't care whether their code handled Chinese or Bengali filenames then it wasn't a bug to do random things with them, which sounded just as bad ten years ago as it does now.
Can you be very precise about what you mean by "broken" or "incorrect" code?
I'm glad that this is what we have for Python now, despite the pain it caused. We'll be using Python for another few decades probably, so we'll reap the benefits.
Nah, I'm good.
edit: This talk he did from pycascades 2018 in particular I remember seeing and being a good retrospective: https://www.youtube.com/watch?v=Oiw23yfqQy8
Python’s rise brought tensions there in multiple ways - business users started wanting longer-term support and tools for migrating large code bases, but relatively few would pay for them, and some maintainers had either drifted away or retired, or simply had less time available due to things like starting families or getting promoted. The 2 to 3 migration really highlighted the gap between commercial open source and hobbyist projects, and I’m sure now anyone would fundraise for support having seen how that worked out.
The other thing we’ve been seeing is a switch to faster releases industry wide and I think that showed some serious tech debt. Projects which have CI & decent tests had a much easier time shipping updates or having two release series for an while, and the 2 to 3 migration really highlighted that. Some of the griping was really showing that older projects often had the frictional disincentive of that tool. That’s still relevant because of the way security issues are forcing more frequent updates now.
Print was a non-issue once you could do "from __future__ import print_function". It was the unicode migration.
All string handling from I/O required at least checking.
The dependency issue was the most crippling, though: because you can't load Python 2 code from Python 3, before your project can begin migrating you have to wait for all your dependencies to update as well. This may involve them changing the types that get passed over the API from 'str' to 'bytes' or vice versa, which is potentially a breaking change.
The core team was swamped with other work around the migration and the community found their response to real world problems lacking. They did things like declaring Python 2 dead long before 3 was usable. Then they refused to fix SSL problems with Python 2, which everyone desperately needed, and went out of their way to oppose a community-led release to fix those problems.
It all ended well. There was another Python 2 release, and Python 3.4 came and fixed most problems people had. It was still slower, but performance picked up and by 3.7 it was just as good if not better. But it was a good ten years during which the response to real world issues could have been a lot better.
All in all, the migration could have happened much smoother. They could have learned from other languages. But ten years is not unreasonable for backwards incompatible changes for a major programming language. The idea that the process could be accelerated by neglecting the old version does not work.
In my personal opinion, the single thing that could have made the transition better for the community would have been the possibility to run Python 2 code in Python 3. It was discussed a lot before the transition and was deemed impossible because of conflicting data types. But it's not impossible, it's just (a lot of) work. It's another type conversion, and Python can already do those. The impossibility to link to old libraries made the conversion a flag day for most code bases, and those are really hard.
For python2, the str class could either contain a sequence of characters, or could contain a sequence of bytes. These are often conflated when using ASCII encoded text, but are very different for any other encoding. In python3, these are represented by the str class for a sequence of characters, and by the bytes class for a sequence of bytes. It’s so much nicer to work with, but required manually separating out the earlier use case.
The whole 2 to 3 debacle was only because somebody thought that naming your string class 'unicode' doesn't sound nice enough or something.
I had clean Python 2 codebases which had been Unicode-safe for years and had good test coverage, so porting to Python 3 was trivial and mostly automated. The projects which were hard were the sloppy ones which conflated bytes and Unicode, and the poor development culture which lead to that also tended to mean they had limited testing, orphaned dependencies, monkey patching, etc. which made the migration hard. I also found a fair number of cases where that process fixed other bugs which had been ignored for years.
Secondly, it seems to me the Python team didn't want to make it possible to write code that works correctly on both Python 2 and 3 simultaneously. They wanted you to write code that only works on Python 3 and tell every single Python 2 user to get lost. Essentially, they wanted to co-opt you as their agent of change; burn your own reputation by abandoning your userbase (or worse, start proselytising Py3 at them) or double your own workload to maintain two codebases. Who wants that?
It's fundamentally an attitude problem. A desire for there to be only one right way to do things, a change of mind of what the right way is, and kicking the chair out from anyone doing it the old right way; the only compromise being to kicking the chair very very slowly. In Java, you can still run code that uses Vector and Hashtable from 1996, they're not even deprecated. They're used by _very_ little code since generic List and Map APIs superceded them 2004, but they're still there.
You need to install either "python-is-python2" or "python-is-python3" packages to get proper system-wide symlinks. Also, it was strictly verboten to give either of two packages as dependencies to workaround migration procedures.
Debian Testing doesn't have Python2 at least for a year now.
Another mistake in Py3 migration was keeping the interpreter name as python so when you had it in path you had a choice of new stuff breaking or old stuff breaking
It was, in the past.
When python2.7 deprecated and removed in Debian testing, python ceased to exist as a command. You need to install these packages (python-is-python{2,3}) to get the python command and point to the correct interpreter you like.
This behavior is consistent in two Debian testing systems, installed 6 and 9 years ago, respectively.
> Another mistake in Py3 migration was keeping the interpreter name as python...
I installed python-as-python3 myself, after python2 disappeared from system to fix an oddball python3 script which bundled as a part of a bigger software package which is not in official repositories.
Maybe they have fixed it, but I didn't bother to check till now. I'm not even sure which program it was.
So, it was an addition to a clean system and didn't inadvertently directed python2 code to python3 interpreter.
I guess nowadays, as the py2 compatibility is a thing of the past, most programs would crash when using that interpreter version.
It will be easier for the Python core maintainers, but introducing a breaking change with the intent that that version 2 will be deprecated has probably caused more distress overall, especially maintainers of other open source projects which rely on a specific python version.
Let's never have the same kind of breaking change again, please.
It wasn't not even that easy, to be frank. 2to3 is not a small project [1] and they had (alas, incorrectly) assumed that there were enough people to have enough tests to be benefited from 2to3, only to be found massively wrong. In hindsight no one had a good idea about language evolution; the modern concensus is a single interpreter supporting multiple parallel versions, also called "editions", but (EDIT: to my knowledge) the first major language with this approach was ECMAScript 2009 (5th ed.) with `use strict` and Python 3 predated it.
Perl did it since ages. You just put
use v5.24
If you tried to run a 5.8 script on a machine without 5.8, you'd get an error as should be expected. If you ran a use 5.6 script on a 5.8/5.10 machine, I think you'd get 5.8, but I can't remember... 5.10 was less disruptive than 5.8.
From the toolchain and language developer side, nobody liked Perl's approach. That's why there was so much effort around Perl 6 (which became Raku) at around the same time.
https://docs.python.org/3/library/__future__.html
That only works with “syntactic” updates, not with deep semantics changes.
Those are why the core team pulled the trigger on an overhaul update. And they were by far the biggest issues during migration, anything which would be gated behind an edition or opt-in was easy.
Not that I've any proof but I kind of find it hard to believe there were no other examples before
But editions & friends are for syntax. Python 3 changed semantics all around. Editions are not an option when you’re changing the langage’s entire text model, especially without static typing.
I don't know where this discrepancy comes from.
It's been 14 years and dropping python2 is still controversial.
It's a story of how not to do a major language upgrade.
It's not quite as bad as "Perl 6" which killed off the whole language, but it's up there with massive mistakes which has cost the industry dearly.
Took a calendar year of ca-a-a-arefully migrating these one by one, all while delivering stuff and making sure nothing falls apart along the way.
Not pleasant. Can't recommend.
(And before anyone asks, a big part of why it’s so big is that it’s very old. So old it predates Django, so, in house framework, in house ORM, etc.)
To be fair it was a place where the Python fans advocated for its use but to management was always a bit skeptical, so we had to make it all seem easy. We had good solutions to internationalization which all broke with Python 3.
We cannot deny everything that happend before Python 3 was released.
Is there a risk it becomes like one of those situations where certain people use a topic simply to make conversation? Or the modern exaggeration to avoid seeming boring? Or a bunch of "oh, it's gonna cost ya" contractors plying the age old lines of car mechanics negotiating basically anything. Someone below referred to carnage. I wonder how far off we are to someone claiming it was actual violence.
I was lucky it didn't affect me much, but I could sympathize if somebody had hundreds of thousands of lines of python2 legacy code that needs to be migrated..
If anyone has any good resources I could browse that might help me understand the full story feel free to share.
So I started with python 2 and found the book crap. The author's idea of teaching is telling others to repeat an exercise a hundred times with all possible variations. There were more than a dozen about printing stuff to a terminal, before you got into any interesting stuff.
From their website, although they added a new course and book for python 3, they are still selling the ones for python 2. Still selling stuff for a version killed 3 years ago requires some fucking audacity.
Later I learned python 3 from other source and loved it. It's what I mostly program with today.
I am stuck on .NET48 at least for another two years (because of webforms frontend) and the last version of EF Core that supports .NET Standard 2.0 is 3.1. They dropped .NET Standard 2.0 like a rock... for what? Few default interface implementations.
Or nullability attributes that are missing in .NET Fx, they could also be defined externally, like R# does. Nope, sucks to be you.
Starting with Java 9, finally the long deprecated APIs started to be removed.
In any case, the issue is that we are forced to write C# 7 and Java 8 code.
Some well known examples, Sitecore, SharePoint WebParts, SQL Server SP extensions, Dynamics, Office AddIns, VS plugins, Solr extensions (many places keep using Solr on Java 8 even if more recent versions exist), Android (unless one goes Kotlin or targets version 12), Forms and WPF 3rd party components (the versions on .NET Core are incompatible due to new designer)...
Compared to Python 2->3, the breaking changes were more obvious as they involved entire strucutres and paradigms being deprecated. Python 2->3 felt a lot more subtle despite being just as damaging.
And if you don't want to use moin2, it can convert the custom markup to Markdown, which you can then use elsewhere.
That's my impression from https://moinmo.in/MoinMoin2.0 anyway.
If they had started a new project called COBRA and just eventually had it over take python the world would be all over it.
But massive breaking changes going from 2 to 3 was a disaster for their audience.
Worse still you could hear the acrimony in Pythons communications on the topic.
> Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3"
> Hey, there is a new interpreter out there called COBRA. We need to rewrite our whole codebase to use it, there isn't a tremendous amount of benefit, but its the new thing from the same people and eventually everyone will use it. Trust me.
Nope, the real life conversation would be "Is 2 still supported ? Yes ? Well then we will migrate when it won't"
But it was a lot easier for the CEO to digest `2 -> 3` as a clear path to the future as opposed to switching to a new language.
Python doesn't exist anymore, everyone's using COBRA. We can dedicate a dozen engineer months to switch to COBRA.
Or thousands to maintain python ourselves...
I suspect a lot of the controversial decusions made doing the 2to3 migration by the python foundation was deliberately designed to avoid a situation similar to what happened to perl when the time came to cleanup some of the old cruft from the language.
It was a necessary change too. Supporting Unicode strings or mixed-encoded strings was absolutely awful in Python 2 and almost not worth doing. Python 3 made that work properly.
Arguably, the only real mistake was using UTF-16 instead of UTF-8 for strings. But back then, nobody knew what would take off and Windows natively uses UTF-16, so...
Raku is a completely different language from Perl. Writing Raku instead of Perl 5 is like writing Rust instead of C++.
Python source files then somehow need to announce what python runtime version they expect.
Having to support old versions forever also should make the maintainers think twice before breaking compatibility again.
The one of the things Microsoft appear to have mastery of is making sure users and devs don't feel breaking changes.
Drivers generally as well as D3D.
1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable.
2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI.
Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
It was also for a time impossible (or close to impossible) to run the same Python code in 2.x and 3.x. It helped when later 2.x versions acquired more 'from __future__ import'.
They really aimed for making it maximally hard to support v2 and v3 at the same time which created a nasty coordination problem: why upgrade if the libraries aren't ready and why upgrade the libraries if there are no users.
Even if you don't get all old code to work, having say 80% of it working means to start using Py3 you'd need to only initally rewrite 20% of the codebase, run tests and off you go, then migrate rest slowly over time.
- Added some stuff to AngularJS to make it more Angular2 compatible so that you could get closer to the target without taking in the breaking changes
- A thing called ngUpgrade let you dual-boot AngularJS and Angular2 together, so that you could transition parts of your program over time without needing to redo the whole thing
- Well documented migration guides for each step, outlining what you need to do in order to move from X version to Y version.
Been long enough for everyone to migrate to python3, and this finally happened.
When I worked on patching/rebuilding all the Python packages for Alpine's upgrade to Python 3.10 I remember quite a few things being broken and needing patches (maybe about 5% of the overall packages), but a lot of those were also test failures due to the new deprecations, so while some stuff did truly break, it was pretty rare.
[1] https://docs.python.org/3/whatsnew/3.10.html (see the removed section especially)
ERROR: gcloud failed to load: module 'collections' has no attribute 'Mapping'3.8 is a bigger C ABI roadblock than 3.10.
I've been slowly porting a lot of my legacy code from 2 to 3 on an as-needed basis, there's a few bits though that are just too huge/crusty/etc that they will never get ported.
But it would be a mistake to consider Python anything but luxury glue no matter how much you've used it for production code, it isn't and never will be a bullet proof language, there are just too many ways in which the runtime can surprise you and the long term maintainability of any Python codebase is always going to be questionable, in part because you will most likely have dependencies on stuff that will silently disappear or change out from under you while you're not watching.
I've been writing Python code pretty much since it was first released and there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change. This as opposed to just about every other language that I've used, which I find very frustrating because Python could be just about perfect. And I'm still sore about significant whitespace ;)
For Java 8 especially, the later reason is particularly amusing, as Oracle's extended support is now slated to go to 2030 (16yrs after release, for comparison Py2.7 got 10yrs), but Java 21, the next Java LTS that should release next year, will be on Oracle's standard 8 year extended support cycle, and thus extended support only goes til 2031. So why would anyone decide, much less how would one justify to a corporate overlord, to spend all the time and resources to refactor their code, upgrade libraries (assuming the libraries themselves upgrade), update build systems, perform extensive regression testing, and everything else, just for a version that would be EOL one year after what they just upgraded from?
The actual migration should you choose to do it was almost trivial. The official conversion script did most if not all the work. The changes were all cosmetic, like "print 42" changing to "print(42)".
I'd say the uproar was about the minorness itself. The syntax had these tiny but otherwise incompatible changes, and for many people, for no good reason. Fo example it was deemed that, as in the example above, print shall not be a statement anymore, but a function instead. Why? Unclear. Meanwhile, Python 3 offered few concrete improvements to many users
So I think the 2->3 moan, of which I was a party, was about that: minor, unnecessary changes that introduced little to no benefit, and yet backwards-incompatible.
print("goodbye, sweet prince")
Lots of abuse of how weakly/poorly/forgivingly typed Py2 is.
Doing the same processes in Py3 is actually headache inducing because of the much stronger typing system.
The effort for implementation and package maintainers to support both versions was considerable, resulting in some notable packages only supporting one or the other.
In the words of the Python maintainers:
We needed to sunset Python 2 so we can help Python users by improving Python faster.
We released Python 2.0 in 2000. We realized a few years later that we needed to make big changes to improve Python. So in 2006, we started Python 3.0. Many people did not upgrade, and we did not want to hurt them. So, for many years, we have kept improving and publishing both Python 2 and Python 3.
But this makes it hard to improve Python. There are improvements Python 2 can't handle. And we have less time to work on making Python 3 better and faster.
And if many people keep using Python 2, then that makes it hard for the volunteers who use Python to make software. They can't use the good new things in Python 3 to improve the tools they make.
Effectively, however, python2 and python3 are different languages. Since they're interpreted, there's now a problem with '#!/usr/bin/env python' in your script: which python version is being invoked? Which language version are modules targeting? It's a mess.
But the poster child for screwing up a language version upgrade is still Perl.
The first 3.x releases were in no way good enough to replace 2.x and should not be counted like this.
Great that Debian finally pulls the plug on it, that means that most if not all of the downstream distros (such as Ubuntu) will probably follow suit, that's a big fraction of the whole Linux eco-system.
I know that Python 2 has stuck around for far longer than anyone wanted and that people were (are?) hesitant to migrate from 2 to 3, but I'm not sure what decisions contributed to that.
So IMO, basically what should have happened is accounting for valid use of features that 3 wanted to kill, and actually offering a path forward, from day one, so everyone could do a migration and actually have it work.
Edit: Also (but connected), 3.0 (and IIRC a couple thereafter) should have been marked as release candidates, because they were.
For us it was a change in string handling that stopped us being able to upgrade. Literally 10,000 things would have to be checked. We saw that red hat was supporting python 2 until 2025 so we decided to keep using python 2 until then. I think that once red hat stops supporting python 2 someone else will keep it running.
Python 2 still makes the world go round.
Some would consider it cheating but I haven't got enough hours in the day. If I were to write some ad copy for Anaconda it would be 'in several years of frequent use this particular user didn't have to resolve a single conflict, it all just worked'.
Which runs counter to just about all of my other experiences with Python and its package managers/distributions/toolchains, some of those stories would end with 'and as a result the whole server was hosed starting from what should have been a routine certificate update' and other such nice adventures.
If you're writing Python code, `poetry` has been the least bad package manager in my experience. It has a lock-file, so it should help avoid supply-side attacks (like the PyTorch one from a few days ago [1]), and it means your local environment and CI/CD environment should have the same packages installed.
I'd also recommend setting the [`virtualenvs.in-project`][2] setting to `true`, to store the `.venv` in the same folder as your code, so that when you delete your code, all of the downloaded packages get deleted too. Otherwise they'll just stick around in your user directory and use up a lot of disk space.
[1]: https://pytorch.org/blog/compromised-nightly-dependency/
[2]: https://python-poetry.org/docs/configuration/#virtualenvsin-...
pip
Did you know pip can execute arbitrary code when installing packages?
(I know someone who will pretend to know my situation better than I will advocate for some "solution;" no, it won't work in a way that won't break some of my priors)
I just wish they would stop iterating on the minor version so quickly. Why are we on python 3.11 (for workgroups, just kidding)? Is there that much of a difference compared to 3.7? 3.7 even has dicts with stable key insertion order and type hinting, so it seems pretty loaded if you ask me.
There's a lot of improvements being made to Python on these minor versions. So while the version bump looks minor, they can make quite a big impact.
3.11 improved performance by 25-60% (depending on use-case). 3.12 is set to improve performance yet again (Special thanks to Mark Shannon, GvR and Microsoft). On top of that there's a lot of quality-of-life improvements for the various parts of the std.lib.
I like this apporach very much, since upgrading to a new minor Python version is somewhat trivial
I'm in the minority here on HN, I can't stand the fact that something I use daily on Windows[1] and can continue to do so forever (because it's a compiled program, and the binaries will likely work for decades) can't run the same code in Linux, where the source is in python, and both it and wx_windows have made breaking changes.
For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day.
It would be like declaring all HEX wrenches and tools to be obsolete one day, and insisting that everything was either 7 sided or heptalobe instead, for "reasons"
It seems completely irrational that Python 2 is excluded.
This isn't like a web site where there is an active party supporting the other end, this is code written in a language that had risen to popularity based on how well it was supported.
And that support has been arbitrarily withdrawn, and the HN crowd seems to cheer it on. I submit that this is part of why the year of the Linux Desktop just keeps receding into the future.
It is not about fashion, it is about resources and manpower. Supporting Python2 is not free, especially post-EOL, and a huge amount of community effort has gone into supporting it. It is not fair to demand that Debian ensure that vendor-unsupported legacy software continue working indefinitely, especially given the environment it would be running on is a moving target that will only diverge further from what was contemporary with Python2 with each release.
>This isn't like a web site where there is an active party supporting the other end
This is exactly like that. The "active party" in this case just happens to be the Debian community.
If you wish to continue using Python2, either stick to running it on an outdated environment such as Debian Buster that supports it natively (and accept the security consequences of doing so), take on the burden of porting it to modern Debian yourself, or seek out one of the commercial support options that exist for post-EOL Python2. You are not entitled to indefinite free labour.
I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.
Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burden.
Python2 has not had a security update since the EOL version 2.7.18. I am not aware of any current CVE's against this version but if one were found Debian would either have to withdraw the package or patch it for any stable versions of Debian. This includes maintaining the build infrastructure for Python2 to be able to patch it if required, bug tracker, etc. as long as Python2 is offered.
> What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023.
I do not have numbers for this, but as the commercial Python2 support I was looking at (Activestate) is "inquire for pricing" I would imagine the equivalent community manpower/resource cost is significant. Just hosting the .deb in the APT repos is cheap - everything else around it is the expensive part.
So it is not so much "the cost of removing it" and more "the cost of keeping it around".
[1] https://www.debian.org/doc/packaging-manuals/python-policy/i...
And of course cue the endless lines of fanboys screaming get used to the new reality, rewrite everything to Python 4 cus Python 3 is EOL and gone folks!
It's a huge usability fail on the part of Python that it's not obvious and easily memorable how to do this.
If you think about it, that's the only way that makes sense; if you wanted to go from, say, UTF8 to UTF16, you'd need to have an intermediate step that was abstract and formatless. Similarly, when you're operating on text, you don't want it to have a particular format; the format should only exist at the edges, where you take text in and output it. The format is a way to communicate with other programs, not components within your program.
My advice would be, if that doesn't stick in your head (totally legitimate), write down a code example and stick it in a personal wiki or something. I find it really helps me to understand something once and more or less copy paste it forever.
This is a key reason why people hated Python 3 so much IMO.
For context I’m a huge advocate of Python 3, except for this (and lambda functions, but that’s another whine session).
https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...
A simplistic summary is that you always decode to unicode and always encode to bytes.
Another way to think about it is that Unicode is an idealized character model that is reified into a byte encoding, usually UTF-8, for practical usage.
It seems to me that this is something a lot of developers don't think too much about until they run into some obscure encoding/decoding issue, but it's kind of a fundamental aspect of programming that's worth spending some time grokking.
The problem is that encode and decode are directional constructs that change depending on context.
That’s a poor UI in Python.
Isn't it true that encode always means text -> bytes and decode always means bytes -> text?
It's really sad that the Python folks committed suicide this way, all over a unicode fetish.
"Everyone has has a chance to migrate" . Doesn't work that way, just yesterday I spent a few hours trying to get scripts that are really good and would take me forever to migrate that are in python2 to work on an ubuntu based distro and this is with pyenv, custom venv,etc... just when you get python syntax worked out you are faced with deprecated or uselessly renamed imports and modules.
This is the shitty aspect of using foss stuff. I don't pay for it so I have to accept their decission. But in the broader sense, inability to influence things like this even with a ton of other people willing to pay for it is frustrating.
You know what would be great? If the community can vote with money pledges. So it you have 1000 people willing to donate $10/month to support python on sysv init then if volunteers don't want the money we get an external person getting paid 10k/month to support these packages even if the corporate types, developers and "devops"/sysadmin people have no use for it.
The free part of foss is expensive but I think the middle ground is to collectively pay for the support. I try very hard to avoid python2, I am not a developer and I very easily lose at least 1h/month on average to resolve these issues.
Do you all know why 2023 will not be the year of the Linux desktop? Because desktops are a commercial market and consumers/users cannot sway what the Linux desktop experience is. They either accept things as they are or pay for them by spending time reporting bugs, troubleshooting stuff, asking questions on random sites,etc... a lot of this has to do with change and maintenance requiring human time and resources. It's great when there are no issues and volunteers donate their time but it would be great to be able to pay with money also to support features or resolve issues. You can even make sure multiple people pay an equal amount to avoid wealthy people having too much or an influence but it still will not affect regular volunteer work.
I was hoping Ubuntu and Fedora would have such features.
Stand-alone applications should use pyenv/venv because you can’t guarantee which version of Python is the system-wide one (and you don’t necessarily want to tie your app to the distro’s release schedule). Dependencies should always be in a venv as to not interfere with the system-wide ones or other applications.
If the removal of Python from distro repos breaks your things then it’s a wake up call and you’ve been doing it wrong the whole time. Fortunately it’s an easy fix.
That does not sound like a user friendly programming language.
The version compatibility of Python is a joke and has been after 2.7 to 3 to. Which is the main reason I don't use Python for anything but bash-like scripts.
And... you believe that Microsoft and Apple are swayed by users? More than Red Hat and Canonical? I don't buy that for one second.
If you want to complain about Python 2 being unsupported by the Python foundation, you're free to. But no distro can in good conscience keep distributing a thoroughly unsupported piece of software that's probably full of security bugs.
Regarding the "year of the Linux desktop" thing: Apple is much more aggressive than any Linux distro when it comes to dropping deprecated stuff and forcing their users to move on. Apple hasn't shipped Python 2 for a long time, they ship Python 3.
What lesson was learned? It seems like a weird corollary of the Streisand Effect: if you announce something's EOL, you'll get more clingy users that keep the product out of the grave, creating a drag on maintenance budgets, but, maybe, if you just stop maintaining and walk away, dependent users will either notice and switch away, or die themselves, and the death will ultimately be quicker and quieter.
(1) As an example: https://news.ycombinator.com/item?id=26168596
LOL that's an ancient bit of copy pasta. Here's a page from over two decades ago that was already describing it as a "classic troll".
Also poeple dont like to change shit that runs well, thats why we have so much legacy stuff around.
In the real world, it doesnt matter if your whole damn business is still running their warehouse system on a DOS program running in a god damn DOS emulator on a Win xp VM running on some linux box. What matters is that it works.
In case you're not trolling: FreeBSD optimizations used by Netflix to serve video at 800Gb/s [pdf][1]
Usenet activity is a very odd measure of deadness to use today.
Although maybe that is exactly what you mean: that the BSDs were already dying in the Usenet era and are still not dead? I think even if they were dying back then, over the course of the past 20 years they may have found their niches to heal and survive in.
Seriously though, that was one interesting language, the number of weird features (the editor is a string) that you'll come across in MUMPS make it fascinating just to study and wonder what inputs into the decision making process around the design trade offs were.
Those are from the 1980s.