> If you’re still on Python 3.8 in 2024, that is a symptom you are suffering from an organizational problem, and it’s likely you have other important upgrades that you’ve been putting off. So your next step should be setting up an ongoing process to update your dependencies regularly.<p>It's painful to read this. I agree, but Python devs <i>hate</i> churn to an extent that seems to have traumatized core devs and major project maintainers and make them act like their hands are tied by backwards compatibility concerns. This is, after all, the same language where Python 3.0 was announced April 2006 and released December 2008, and we didn't see the last 2.x release until April 2020 (and this is after it had been publicized for years that there would be no more releases after Jan 1 2020, which was in turn giving the 2.7 branch an extended lifetime). And even then, you can find people in 2024 pining for the old version and complaining about supposed design mistakes like "maybe it's bad to treat byte-sequences like strings implicitly without declaring a text encoding, in the language that asserts that explicit is better than implicit, leading to users having to check Stack Overflow to understand why they got a UnicodeDecodeError from trying to encode or vice-versa", or "maybe we shouldn't teach brand new programmers, on the first day, to put an unintentional arbitrary code execution exploit into their programs and not tell them about it". Even granting that 3.x has broad acceptance now, one of the better known Python book authors from the old days (Mark Lutz) has a webpage dedicated to the argument that basically every major feature added after 3.4 is a step backwards.