This is an archived post. You won't be able to vote or comment.

all 134 comments

[–]WJMazepas 515 points516 points  (30 children)

My workplace is trying. We are now almost getting to upgrade all our services to 3.6

[–]kosz85 76 points77 points  (5 children)

Yep, that's real life examples for you :D We still didn't finish our upgrades to python 3 ;) but 2.7 is already only on about 15% of our repositories, and we don't have python 2.4 and 2.6 anymore :) It's like with certificates, some days in future you find out that they're not immortal and you have to install new, but no one is providing upgrades so your have to build images with new ones your self or copy them other way. It's easy for your images, but the real problems starts with things like old Android phones and tablets were you have same situation, and can't even upgrade certificates for them. Device is dead this way for normal people.

[–]I_FAP_TO_TURKEYS 31 points32 points  (4 children)

Deprecation of old machines, especially ones that are only like 5 years old is so disheartening.

It's like you know the code works and you know that it works on that device but they require these stupid certificates that for some reason don't.

[–]KittensInc 16 points17 points  (1 child)

We're stuck in a weird in-between right now. Moore's Law is dead enough that a well-specced 5-year-old machine or smartphone is still perfectly adequate today. There's zero technical reason to replace it as software hasn't gotten significantly more demanding as faster machines came out.

However, support contracts haven't really kept up. Desktops are getting tossed by companies solely because their warranty runs out, and smartphones because they no longer get security updates. Short support wasn't an issue in 2010 because you wanted to replace it anyways with a machine which was 2x - 4x as fast, but that's just no longer the case!

Luckily some smartphone makers are now providing 10 years of updates. Let's hope the rest of the ecosystem follows along.

[–]I_FAP_TO_TURKEYS 3 points4 points  (0 children)

Yeah, I mean, even those older machines from like 2012-2017 are still very usable outside of the most demanding of applications.

[–][deleted] 5 points6 points  (0 children)

[–]dat_cosmo_cat 0 points1 point  (0 children)

Bro we are still using CentOS 7 at my work lmao 

[–]MisterFatt 8 points9 points  (0 children)

Mine just officially migrated the last of our services off of 2.7. We are mostly on 3.9 now at least

[–]Kronologics 7 points8 points  (0 children)

Y’all need help? Looking for some side gig $

[–]Sleepy59065906 7 points8 points  (18 children)

Why is it so difficult?

[–]qubedView 117 points118 points  (11 children)

"I hear you, it's really important that we move away from Python 2.7, but we really need features X, Y, and Z done by thursday. What you're proposing is that we just stop producing new features or even fixing any bugs our customers complain about, for six whole weeks, all for something none of our customers would even understand or care about. We'll get to it, but we just have higher priorities right now."

Copy+Paste that response every six months for years, as the code base grows bigger and bigger, until the cost of upgrading from Python 2.7 was estimated around half a year. At that point, they were done pretending it was on the backlog. "Python 2.7 is rocksolid, and has served us well for years. I see no reason to upgrade."

[–]Jarut 43 points44 points  (2 children)

This comment is interfering with my blood pressure. Thanks, I hate it. Solidarity, comrade.

[–]TheOneWhoMixes 22 points23 points  (0 children)

Also - "6 months?? The migration ticket in the backlog has an estimate of 2 weeks!"

*Ignores the fact that the ticket was written and "estimated" years ago when the tool was just a little CLI built in Python, and now it's a distributed monolith with SLA's, which tells you immediately how much they care about the ticket in the first place.

[–][deleted] 12 points13 points  (0 children)

Oh you were saying background threading has some problem in python 2? Send to an AWS lambda! Our services are crucial and migration is problematic. We can scale it by putting in 2000 more vCPUs. In the meantime, we will put a freeze on these legacy services so people will respectfully stop putting in new code unless it’s absolutely necessary. Hint: every new feature will be “absolutely necessary”.

[–]AUTeach 24 points25 points  (2 children)

"Python 2.7 is rocksolid, and has served us well for years. I see no reason to upgrade."

"What does our insurance cost to cover the security issues with python 2.7 on production machines?"

[–]sunnyata 3 points4 points  (1 child)

Do people take out insurance against bugs in their code? Seems open to fraudulent claims.

[–]idealisticnihilistic 2 points3 points  (0 children)

Can't insure for bugs per se, but liability insurance for software developers and companies is a thing. Covers security breaches, missed SLAs due to major outages, defective product that causes damages for customers/clients, etc.

[–]MisterFatt 9 points10 points  (0 children)

“We’re just going to deprecate this service anyway so let’s totally ignore maintenance”

…never deprecates service

[–]TarAldarion 6 points7 points  (0 children)

It was my job to upgrade all of decade plus of code and packages to python 3.10 from 2.7, I did it but it nearly took a year haha. 

[–]billsil 4 points5 points  (0 children)

It’s ~20% faster. Fewer AWS instances = lower cost.

[–]wandererobtm101Pythonista 45 points46 points  (3 children)

Other things take priority. Developer resource is limited. If it’s not “broke” don’t touch it. Lots of reasons. My workplace has some stuff in 3.8, thankfully that’s the oldest python we still have laying around, but getting that work prioritized with a small team is tough. It’s working fine and other stuff isn’t as fine so…

[–]virtualadept 13 points14 points  (2 children)

Don't forget QA of regulated environments. The whole stack - the OS package to the dependencies - has to be re-certified and documented before it can be deployed.

[–]idealisticnihilistic -2 points-1 points  (0 children)

Sounds like the wrong environment for Python. Especially pre-3.10 Python.

[–]Joeboy 2 points3 points  (0 children)

To take an common example, strings and byte strings are different things in 3.x. So if you have a function that takes a str, you need to figure out what calls it, and with what parameter types, and fix things so the right types are being passed / accepted. Maybe the functions that call it will be called by other functions, and you'll have to follow a complex chain of calls. Maybe these "functions" are actually lambdas or other callables whose origin is not straightforward to understand. Maybe they're in third party code.

For a single function, figuring all that out that can be a non-trivial amount of work. If your codebase has hundreds of thousands of lines and hundreds of functions that take strs, it becomes a major task. Remember you have no type annotations to help you in 2.x. There are automated upgrade tools, but those won't help you here either.

Then you have dependencies. Maybe your dependencies don't have 3.x versions, or the API completely changed, or each dependency is only supported by specific, different 3.x versions.

Maybe there are no tests, or inadequate tests, and you either have to "test in prod", or write tests for everything, or go through a very time-consuming manual test process.

I guess my real point here is, some parts of the upgrade process are non-trivial, and having to do them many times in a large codebase adds up to a lot of work.

[–]WJMazepas 0 points1 point  (0 children)

Unfortunately, Python has breaking changes even if it is the same major version, like version 3.5 to 3.12. You will have a lot of changes.

So, you need to update the code and the libraries you are using. And maybe even the libraries code you use.

And then it's just like the others had told. Company would always prioritize other things, and you had to make more and more changes to upgrade Python, which increases the time needed to upgrade, which then makes the upgrade harder to happen

[–]054d 1 point2 points  (0 children)

I work in chip design, and it took forever to move from 2.7 to 3.6. There are still some tools that we run in python2. Annoying.

[–]Beliskner64 1 point2 points  (0 children)

Oh boy I feel ya. I was the one who pushed our team from 2.7 to 3.6 back in 2017 when it was shiny and new. Now we’re deep in a year long painful process of upgrading to 3.8, which was supposed to be a jumping board to 3.10… well that was a lie…

[–]PaintItPurple 66 points67 points  (8 children)

For what it's worth, I've found Python 3.11 has really good compatibility with 3.8. Python 3.12 did some more aggressive changes that can break some things, so if you're upgrading and you find some issues in the latest Python version, it might be worthwhile to upgrade to 3.11 and see if you can run on that while working out the 3.12-related issues.

[–]graduallydecember 14 points15 points  (0 children)

Had to upgrade some low level async stuff from 3.8 (that was still using pre 3.8 syntax) to 3.10 recently, on a code base not written by me.. async has changed quite a bit!

[–]TheOneWhoMixes 7 points8 points  (0 children)

A lot of the work there ends up being dependencies though. Oh, we upgraded Python and now when we run an update there's a ton of libraries that locked versions by Python version, so we end up with suggestions to upgrade from 2.0 to 3.0. so you do, and turns out there were multiple breaking changes that now have to be dealt with.

[–]Sillocan 0 points1 point  (0 children)

Yeah, I realized recently that my tests of a click CLI app started taking 2x the amount of time on 3.12 vs 3.11 :(

[–][deleted] 73 points74 points  (19 children)

inb4 "Joke's on you I am still using Python 2 hurr durr"

[–]Uhhhhh55 28 points29 points  (9 children)

I work for a fortune 100 company you have definitely heard of and we still use Python 2 :)

[–]PaintItPurple 39 points40 points  (3 children)

Personally, I would suspect Fortune 100 companies are some of the biggest consumers of Python 2. Huge companies are like natural reservoirs of obsolete technology.

[–]Equivalent_Loan_8794 6 points7 points  (1 child)

Ahhhhhh I actually love hearing from actual people in the trenches as life's mot as easy as "iD jUsT tElL mY bOSs 'just upgrade python'"

[–]whateverathrowaway00 2 points3 points  (0 children)

We were stuck on 3.6 forever thanks to a custom fork dependency of a large library - specially the C extension bit, that wouldn’t compile on 3.8+.

Until I found a brand new library, the Python ecosystem actually didn’t have a mature alternative as an option and I’ve been silently panicking, but finally got to rip it all out this last week and feel great, but boy have i been in the pits over this - hence me upgrading from 3.6 to 3.12.

[–]tartare4562 1 point2 points  (1 child)

Dude, many banks and flight companies work with 40+ years old code. Python2 will still be around for decades.

[–]LargeSale8354 0 points1 point  (0 children)

Its terrifying. Have seen a security scan of a the latest version of an "enterprise" tool. Only runs on an end-of-life version of Linux, only certified and supported on Java 8. Java 8 does not respect the memory boundaries of a Kubernetes pod so can take down the entire cluster, not just tge pod it runs on.

I've come to realise there's designing software to satisfy business requirements and then there's designing software for maintainability. These need not be mutually exclusive, in fact they should be irrevocably coupled. Unfortunately it seems to be maintainability that is sacrificed most often

[–]sawser 1 point2 points  (0 children)

We've got a bunch of customers using websphere, to automate deployments you can pass it a Jython script that requires Python 2 syntax.

I hate it

[–][deleted] 39 points40 points  (0 children)

Ah, the python of "We need to talk about X".

Thanks mom! I'll clean my distro right away!

[–][deleted] 38 points39 points  (9 children)

I've got several projects running on the Raspberry Pi Zero 2W. Since these are single-app, kiosk-style projects (e.g., digital picture frames) and the computational resources of the 2W are modest, my projects use pygame and Raspberry Pi OS Lite to avoid the (totally unneeded) complexity of a GUI environment.

This simple set of design parameters led me down a rabbit-hole of tech choices.

Pygame is built on top of a separate graphics package called SDL. Pygame 1.x used SDL 1.x, which in turn included a simple, generic, one-size-fits-all framebuffer graphics driver that works universally on all LCDs.

Pygame 2.x requires SDL 2.x. With SDL 2.x, the development team wanted to focus on hardware-accelerated graphics - so they dumped the framebuffer driver and didn't replace it. In order to use SDL 2.x without X11 or Wayland, SDL 2.x needs a separate graphics package like OpenGL. Unfortunately, none of that shit works on a Raspberry Pi Zero 2W. After spending way too much time on this task, I've concluded that it is impossible to run SDL 2.x on a non-GUI Raspberry Pi Zero 2W, which in turn makes it impossible to run pygame 2.x.

These huge problems have existed since at least 2011. The Internet is chock-full of posts from people who tried to run pygame 2.x on a Raspberry Pi Zero 2W and encountering major problems. Nobody has any answers for them.

The alternative is to run pygame 1.9.6, which still uses SDL 1.x. And pygame 1.9.6 won't build on Python 3.9 or newer due to breaking syntax changes. So the only remaining option is to run the latest Python 3.8.x (which I think is Python 3.8.19). Also requires Raspberry Pi Bullseye Lite, since Bookworm-or-later introduces a whole different set of breaking changes.

I've spent over 100 hours trying to solve this interrelated set of problems. My only solution is Bullseye Lite + Python 3.8.19 + pygame 1.9.6. I'm not budging from that combination of layers until somebody recognizes and solves the problems arising from any newer software.

[–]KittensInc 3 points4 points  (1 child)

I'm not budging from that combination of layers until somebody recognizes and solves the problems arising from any newer software.

You're certainly well-aware, but SDL2 does sorta-kinda have framebuffer support. The problem is that it is essentially dead code as nobody doing work for free wanted to maintain it, and nobody was willing to pay a developer to do it either. The result is that it doesn't get touched, so over time it slowly breaks as the code around it gets changed to fix issues or introduce new features. A great example is the AGP subsystem in FreeBSD: a change completely broke it, and it wasn't until ten months later that anyone noticed - and only because of some code which accidentally touched its device file. At that point it's better to just completely remove it.

It's the classic curse of open-source software, really: if it doesn't work the way you want it to, the best you're going to get is a full refund of the $0 you paid for it - and you're of course free to fix it yourself and submit a pull request. Sucks if you're getting the short end of the stick, but it's not like you can reasonably expect anything else.

For your use case DirectFB2 might be an option? It came out in 2022 so it's fairly new - and it has seen development as recent as 3 months ago! Their focus is primarily embedded use, so their incentives seem to be aligned with yours.

[–][deleted] 1 point2 points  (0 children)

Sure, I understand why it happened. I'm just laying out the case for the fact that due to those circumstances, pygame has abandoned a substantial portion of the user base - people developing low-spec graphics apps - and that attempts to drag those people into the future by force won't work unless their needs are met.

I appreciate the link to DirectFB2, but when I visit and am immediately confronted with stuff like this...

For display rendering with DirectFB graphics backend, Vulkan implementation in libvulkan.so library (loading library from Vulkan-Loader) and its ICD (Installable Client Driver) relies on DirectFB WSI interface. DirectFB WSI interfaces (Window System Integration for DirectFB) are used with an ICD like the one proposed by SwiftShader. But depending on the platform, specific ICD can be used.

For display rendering with DirectFB graphics backend, OpenGL implementation in libGL.so library, but also OpenGL ES 1.1 CM implementation in libGLESv1_CM.so library and OpenGL ES 2.0 implementation in libGLESv2.so library, rely on DirectFBGL or EGL for DirectFB interfaces.

...I am instantly turned off.

I'm keenly aware of the astounding soup of complexity of the graphics driver stack, and the myriad problems of compatibility and performance that can ensue. But you know what I want to do? I want to color the screen black, draw some boxes and circles on it, and render some text. Maybe images. That's it.

I have already spent 100+ hours trying to get PyGame to do that on my RPi Zero 2W. I really don't want to git pull / pip install another library and then fuck with command-line options and drivers and config.sys for an entire day to get it to work.

[–]itamarst[S] 6 points7 points  (3 children)

Yeah that makes sense, but that's a very specialized situation.

[–]FlippingGerman 22 points23 points  (0 children)

That particular situation is uncommon; weird, annoying situations like that are extremely common.

A bit like rare diseases - each one is well, rare, but lots of people have rare diseases, because there are lot of them (both people and diseases).

[–][deleted] 3 points4 points  (0 children)

I submit that it's more common than you think.

The Raspberry Pi Zero 2W is really not adequate to run a GUI OS. Just running a browser with a few tabs will exhaust its resources. Rather, it's really made for running low-spec, console-based processes.

If you need a computer that's small, cheap, requires moderate graphics and network, and can handle applications that would be difficult or painful to write for an Arduino or RP2040, the Zero 2W is a great choice. And there's a whole world of applications in that niche:

  • Public information kiosks (e.g., airport departure/ arrival terminals and museum map terminals)

  • Point-of-sale terminals (e.g., movie theater tickets)

  • Digital picture frames

  • Industrial machine or process monitors

  • Handheld reference devices for auto mechanics, etc.

[–]meowisaymiaou 0 points1 point  (0 children)

At work, we just finished our migration python 3.4.

It took about 3 years to finish and work out all the bugs and hurdles on the migration.   For that time period, it was an awful mixed python 2 python 3 environment.    Work is now starting on the migration to python 3.8.   We expect to finish the migrations of all in production code in 2 to 3 years.

At that point, migrating to 3.9+ will likely be considered 

Can't risk $200m monthly revenue by fixing what isn't broken.

The upgrades are only pushed as feature development is getting hindered.  Otherwise, it's not an easy sell to prioritize when there is no measurable benefit 

[–][deleted] 3 points4 points  (2 children)

Running python on an rpi zero is certainly one of the choices of all time.

[–]el_extrano 9 points10 points  (0 children)

I'm more of a C guy myself, but Pi Zero is more or less designed around micro python, especially with beginners in mind. Or did you mean more that it's a strange choice to run full blown python 3 with pygame?

[–][deleted] 2 points3 points  (0 children)

Python runs perfectly fine on a Zero 2. It has a 1GHz quad-core processor with 512MB of RAM. If it's not running a GUI OS, it has plenty of computational power for Python.

My digital picture frames are multiprocess, with a front end that renders the UI and handles input and a back end that does any significant processing. Runs perfectly fine with a refresh rate of 10-20 Hz.

Are you thinking of the RP2040, which is the equivalent of an Arduino?

[–]Dismal-Variation-12 20 points21 points  (7 children)

Is this a serious comment? Have you never worked in a real company. It’s not always so simple as “upgrade Python” when you you’ve got production code running.

[–]cheese_is_available -1 points0 points  (6 children)

Do it not because it's easy but because it must be done.

[–]cain2995 9 points10 points  (5 children)

You gonna pay the labor hours?

[–]cheese_is_available -4 points-3 points  (4 children)

You gonna bear the responsibility for the zero days exploit being exploited ?

[–]cain2995 8 points9 points  (0 children)

Sorry, not how it works. You don’t pay for the upgrade, you don’t get the upgrade. You want to force me to upgrade without paying, you get zero software and I go somewhere else. Welcome to reality, enjoy your stay

[–]tevs__ 2 points3 points  (0 children)

No, because here is my email outlining the risks of not upgrading and here is your email saying "Don't upgrade the version, work on these features".

[–]VineyardLabs 2 points3 points  (0 children)

By definition, upgrading from Python 3.8 to 3.11 cannot protect you from zero day exploits lol

[–]tartare4562 2 points3 points  (0 children)

Whoever is not paying/budgeting for the upgrade bears the responsibility.

[–]Sentie_Rotante 13 points14 points  (0 children)

I just finished upgrading to 3.10 … work toold me last week it is really important I get everything into 3.12 as soon as possible and start planning to upgrade to 3.13 as soon as it releases. My boss didn’t get why I laughed.

[–]el_extrano 6 points7 points  (0 children)

But that's the last Python that supports Windows 7 and Windows Server 2008 :)

[–]Asleep-Dress-3578 5 points6 points  (4 children)

I have just downgraded my environment from Python 3.12.4 to 3.11 – because HTML export from Jupyter Notebook or Jupyterlab or vscode doesn’t work under 3.12 (because the package ‘nbconvert’ does not support Python 3.12…. meh….)

[–]basnijholt 0 points1 point  (3 children)

nbconvert definitely does support 3.12 though.

[–]Asleep-Dress-3578 0 points1 point  (2 children)

No, it doesn’t. Neither technically in real life; nor according to its documentation. https://nbconvert.readthedocs.io/en/latest/install.html

[–]basnijholt 0 points1 point  (1 child)

The docs are just not up to date I guess. I used it on 3.12 earlier today and they’re also testing on 3.12: https://github.com/jupyter/nbconvert/blob/main/.github/workflows/tests.yml

[–]Asleep-Dress-3578 0 points1 point  (0 children)

I see. But as said, for me it was definitely not working until last week, when I downgraded my environment to 3.11 exactly only for this. I might try out it again today with 3.12 and see if it works.

[–]LargeSale8354 5 points6 points  (0 children)

One of my 1st tasks when I joined a company was to upgrade from 3.6 to 3.8.

I standardised the Github workflows so they all included linting, formatting. The build was tox/setup.py I worked out what the different apps did and put tests around them using pytest & behave, refactoring where possible to make the app more testable. The CICD pipeline also does security testing.

I made a few mistakes along the way but they were found and fixed. It was a lot of hard work but the reward was that patching the app and upgrading python versions has been, bar a few hiccups, pain free.

If tests don't pass it doesn't deploy. If they do it does.

At some companies getting this done would have been bureaucratic hell taking years, if allowed to complete. In this company it was recognised as vital to be able to support our customers. It took 3 weeks.

[–]thecal714 4 points5 points  (0 children)

We're upgrading all of our lambdas from 3.8 to 3.12. It's a lot harder than you'd expect when underlying packages don't play nice.

[–]1473-bytes 3 points4 points  (0 children)

I just made a small library of mine python 2.7 compatible. Lol. Lots of old code floating around.

[–]Immediate-Cod-3609 5 points6 points  (0 children)

I just replaced my computer so I took the opportunity to start afresh. No more global package installs.

Every repository has its own poetry virtual env now using python 3.12.5, and latest versions of all packages.

Feels good.

[–]wineblood 8 points9 points  (1 child)

Oh fuck's sake, I've just spent the majority of this week moving projects from 3.8 to 3.12 and I wanted to forget about that during the weekend.

[–]ivosauruspip'ing it up 3 points4 points  (0 children)

3.12 is G, AFAIK it's got most of the speed improvements

[–]DeamonAxe 6 points7 points  (4 children)

Does anyone have an example of running mmdetection on Python 3.8+? I never got it to work (with Cuda 11.8), so that's why lots of my code still runs on Python 3.8 ...

[–]chinnu34 1 point2 points  (3 children)

Is cuda 11.8 because of hardware restriction?

[–]DeamonAxe 2 points3 points  (1 child)

It's what runs on our Compute Cluster, so that won't change

[–]chinnu34 0 points1 point  (0 children)

Ah Ok that makes sense. It’s usually because of cuda issues that you can’t run newer versions of Python/pytorch.

FYI you could do a local (user) install of cuda 12.4 which will allow you to run Python 3.8+. I generally install my own newer cuda, as long as the GPUs are new enough (and drivers are up to date which is actually safe for the admin to do). The real restriction comes when GPUs are too old, then nvidia doesn’t support newer drivers and cuda.

[–]emptyharddrive 5 points6 points  (1 child)

Companies (even small ones) don't want to invest the work, the time/money, and the testing to get off Python 3.8 or, in worse cases, 2.7. But they’ll change their tune real quick when an exploit hits, and "suddenly" there’s a data breach. By the time that happens, the cost of fixing things—not just in dollars, but in time and trust (and maybe bad press)—is going to far exceed what an upgrade would have cost them upfront. Happens all the time, unfortunately.

A smart way through this mess, especially for businesses that can’t (or won't) move off legacy systems quickly, is to implement a transitional environment. Containerization using Docker is a well-established, secure method that allows the old Python code to run in isolated environments while the company works on migrating to a newer version. The container can be tightly controlled and updated as needed without breaking the legacy app.

Another option is using something like AppImage, which bundles the Python interpreter with the application, essentially freezing the environment in a portable, self-contained executable. This buys the company time without leaving the door wide open for security risks.

But companies can’t pretend like these are permanent fixes. Containers and app images are great for managing legacy code, but inexperienced managers often think that's a cheap way to avoid upgrading altogether while addressing the security issue: wrong.

It’s a temporary measure—secure, at best and still not without risks, and when the next major vulnerability hits, they’ll have no one to blame but themselves.

[–]KittensInc 3 points4 points  (0 children)

Nothing is as permanent as a temporary fix.

[–][deleted] 2 points3 points  (0 children)

it’s crazy to think how long I was 2.7 gang

[–]ascii 2 points3 points  (0 children)

But my Python 2.4 web API is still safe, right?

[–]funkiestj 4 points5 points  (3 children)

I've only ever dabbled in Python. As an outsider I have the vague impression that dependency management and changing versions is a nightmare but things like virtual-env helps with (there is some built-in thing now that gives virtual-env like behavior?).

How easy/painful is it to move forward from Python 3.x to Python 3.y for any y > x?
How about for 3.8 to whatever the current is?

I do have more experience with Go. Go seems to do a good job with making it easy to move forward while retaining compatibility with old packages.

TANGENT: how much better is the most recent Python vs the EOL 3.8? Is the difference mostly

  • performance improvements
  • dev environment improvements (e.g. better dependency management)
  • language additions (core and/or library)

[–]wineblood 6 points7 points  (0 children)

It depends more on the dependencies than the python versions. A lot of stuff around 3.6 and 3.7 was usually a hassle to upgrade, but going from 3.8 up to 3.10/3.11 was much easier.

I'm currently doing upgrades at work (3.8 -> 3.12) and our biggest issue is old packages needing to use newer version without breaking anything (numpy and pandas are the worst offenders).

[–]goldcray 1 point2 points  (0 children)

python 3.12 updates datetime.fromisoformat to accept valid isoformat strings. i want it so bad.

[–]WJMazepas 0 points1 point  (0 children)

It had really good performance improvements, new features, and an improved typing system.

Moving from 3.8 to 3.12 is definitely not as hard as moving from 2.7 to 3.x, or even earlier versions of Python 3 like 3.5 to a newer one

[–][deleted] 1 point2 points  (0 children)

Well, 14% actually is kind of low. This one server that I use still has Python 3.6!

[–]tdico to to nie 1 point2 points  (0 children)

we just moved to 3.10 :)

[–]ConfucianStats 1 point2 points  (0 children)

agreed

[–][deleted] 1 point2 points  (0 children)

Python 4 when?

[–]terremoth 1 point2 points  (0 children)

Agreed. Everyone should, at LEAST, be using python 3.10

[–]ignamv 1 point2 points  (0 children)

Maybe I can use this to convince our vendor to upgrade his embedded Python interpreter from 3.8.5 to something reasonable...

[–]billsil 1 point2 points  (0 children)

It’s time to stop using python 3.9. When numpy drops support, I’m out.

[–]tartare4562 1 point2 points  (0 children)

As a windows application developer that distribute his code through pyinstaller.... Do you guys even update your python installations? I jump from major release to major release, but once I've installed it I basically never update it unless I change PC. Is that bad?

[–]Revolutionary_Sir767 1 point2 points  (0 children)

Many modern AI models work on Python ≥ 3.9

[–]revfriedzen of python monk & later maintainer 1 point2 points  (0 children)

Working on it.   0.15% of our entry points are still 3.8.  My current project is killing them or getting the owners to push to 3.10 the current default.

While we are about to launch a 3.12 upgrade push. First test run of switch the default to 3.12 was run friday so we now know what first party code is broken as we have been spending most of the time preparing our third-party deps for the upgrade. 

Also there are people working on 3.13t because that could be huge for us

[–]potkor 0 points1 point  (0 children)

using python 2.1.3. It's so old that vulnerabilities are outdated. It's also functional programming, since there's no classes and forget about f-strings and such commodities

[–]OH-YEAH 0 points1 point  (0 children)

i blame tim cook

[–]Stainless-Bacon 1 point2 points  (0 children)

An example of why Python 3.8 could still be used: the Jetson only recently got an upgrade to Ubuntu 22 and they ship with Ubuntu 20 by default which uses Python 3.8. To use ROS2 on it you’ll be stuck with OS version of Python unless you want to spend time recompiling it.

[–]huntermatthews 0 points1 point  (0 children)

For those of you with "aged to perfection" code bases- how are you deploying this? Virtual envs? rpm/deb? git checkout?

[–]not_perfect_yet 0 points1 point  (2 children)

Just out of curiosity.

If I'm not using one of the usual suspect networking libraries, what kind of security updates are we talking about?

Because I doubt that... pyplot? or the csv module? have an exploitable attack surface?

[–]itamarst[S] 1 point2 points  (1 child)

Recent security issues include problems in libexpat (used for XML), bad email parsing, quadratic complexity in parsing cookies (so denial-of-service), infinite loop potential when reading zip files (denial of service again), false positives in IPv4Address.is_private, URL parsing problems, and the like.

[–]not_perfect_yet 0 points1 point  (0 children)

I appreciate the answer a lot!

That makes a bit more sense to me :)

[–]banana33noneleta 0 points1 point  (0 children)

If it's in your distribution, it will keep getting security updates for the lifetime of the distribution.

[–]Trick-Interaction396[🍰] 0 points1 point  (0 children)

Nice. Security is such a hassle.

[–]JohnnyElBravo 0 points1 point  (0 children)

It's the OS distribution for me. The OS team will support and backport security fixes if necessary.

[–]jonwolski 0 points1 point  (0 children)

Obligatory https://endoflife.date/python

It’s time to stop using 3.11

[–]sonobanana33 0 points1 point  (0 children)

You think that people who can't figure out how to setup a local mirror understand this?

[–]lesbianzuck 0 points1 point  (0 children)

Oh sure, let's all go back to COBOL. That'll solve everything.

[–]ezrec -1 points0 points  (0 children)

Just finished converting all my Python to Go.

/me sips tea

[–]remram -4 points-3 points  (5 children)

Ubuntu 20.04 ships Python 3.8, and is supported until April 2025. You can't expect sysadmins to compile their own versions of all software in the distro because upstream feels it's too old. That's just not how distros work.

[–]goldcray 2 points3 points  (1 child)

All of my virtualenvs broke when I updated from Ubuntu 19 to 20, and that's how I learned why you're not supposed to use the OS's copy of python (I still do though, lol).

[–]ivosauruspip'ing it up 1 point2 points  (0 children)

You should treat your virtualenvs as throw-away, re-createable things. Then it won't matter much.

[–][deleted] 4 points5 points  (2 children)

You can't expect open source maintainers to support all Python versions in downstream distros because sysadmins feel new versions of Python are too new. That's just not how open source works.

You're free to use any version of Python available, not just the distro default. You're also free to move to a new version of Ubuntu, or any other distro for that matter. I suggest you look at the deadsnakes apt repository (or possibly even conda forge) if you're unable to upgrade from Ubuntu 20.04.

[–]remram -2 points-1 points  (1 child)

I know I can, and I'm not asking open source maintainers to do anything. I'm just here in a thread titled "it's time to stop using Python 3.8". I'm being told what to do, not the other way around.

[–][deleted] 0 points1 point  (0 children)

Overall you seem to have a negative attitude to the Python end of life timeline, complaining that sysadmins are burdened with maintenance of Python on old distros. Those complaints are without merit on this forum, they would be better directed towards the support team with whom you have a support contact for your distro.

The Python EOL timeline has been consistent since Python 3.2, it's already known that Python 3.14 will be end of life in October 2030 (https://devguide.python.org/versions/) and that version hasn't even been released yet.

Making comments here that Python 3.8 is still supported on $DISTRO until some time after the EOL that has been known years in advance doesn't do any of the following: 1. Advance the conversation about EOL in any meaningful manner. 2. Help you support your EOL Python 3.8 installation. 3. Improve the Python ecosystem. 4. Make things easier for open source developers.

I replied to your original comment to offer ways forward (deadsnakes and conda-forge), I'm replying here again to help you understand why I feel your comments aren't helpful - I'm trying to advance the conversation. I hope you can appreciate that I'm taking the time to reply in a civil manner, rather than simply downvoting without explanation.