> Used to be a viable strategy until they started to drop modules from the standard library at every single release.
That’s a bit of a ridiculous statement, there’s a small number of very-long deprecated modules removed in 3.12, and some more recently deprecated modules in 3.13. And these things are old, largely or completely unmaintained, and usually complete obsolete.
I’d be surprised if anyone has a script that’s been adversely effected by this, and if they did it’s because they stopped maintaining it years ago (and also chose to both silence warnings and upgrade interpreter versions without reading the release notes).
Consider that the python foundation absolutely has the resources to put a developer to maintain them.
If they don't is because they don't want to.
> and usually complete obsolete
The amount of modules I've had to patch to keep working on 3.12 tells me they aren't as obscure and unused as you think they are.
> I’d be surprised if anyone has a script that’s been adversely effected by this
I'd say that over 99.9999% of python users do not download python from python.org. They use whatever is on their system. Which means that updating an LTS distribution will create mayhem. And that's considering that most modules have already been patched by the distribution maintainers to fix all the brokenness introduced by the new python version.
Also, a bash script from 30 years ago still works fine. A python script from 5 years ago doesn't start.
>Consider that the python foundation absolutely has the resources to put a developer to maintain them.
The resources to pay someone doesn’t mean that someone with interest and knowledge exists, especially for modules that were formally deprecated in Python 2 and which will never be reinstated. Lots of this stuff is just cruft, most of which has an obvious replacement, and if it doesn’t there’s a decent chance it’s not been used in years by anyone and if it ever had a reason to be in the standard lib, that reason is long gone.
> The amount of modules I've had to patch to keep working on 3.12 tells me they aren't as obscure and unused as you think they are.
If that number is at all significant, where are the issues pushing back against deprecation and removal? It’s not like there hasn’t been a formal process for all these modules. What got deleted in 3.12 was well documented and easily caught just by catching DeprecationWarning… anyone getting surprised by these modules going missing isn’t doing due diligence.
> I'd say that over 99.9999% of python users do not download python from python.org. They use whatever is on their system. Which means that updating an LTS distribution will create mayhem.
And I’ll pretty much guarantee you that 99.9999% of those users haven’t heard of, much less imported, any of the modules that have been removed.
> And that's considering that most modules have already been patched by the distribution maintainers to fix all the brokenness introduced by the new python version.
But again where are the issues and hands being waved that these issues are wide-spread enough to halt or reverse the deprecation process? If distro maintainers are simply patching everything for users who are constantly advised to leave their system Python alone and they’re not reporting the issues then those distro maintainers are harming everyone.
> Also, a bash script from 30 years ago still works fine. A python script from 5 years ago doesn't start.
I’ve written plenty of Python scripts that are still running on the interpreter and stdlib they were authored for, decades later. I’m also keenly aware that most of those scripts could not be written in Bash without reimplementing a significant portion of the Python standard lib and ecosystem, none of which was materially affected by the 3.11>3.12 removals.
For instance, some fairly commonly used Linux apps like ulauncher, autokey, fail2ban and xpra depend on pyinotify which hasnt been maintained for the last 6 years or so, which is why fedora, arch and nixos now includes patches to make it 3.12 compatible. I don’t find it very unlikely that your inhouse script could be using it too.
> The resources to pay someone doesn’t mean that someone with interest and knowledge exists
That's why you can pay people. So that despite their disinterest they will read the code and acquire the knowledge needed.
> especially for modules that were formally deprecated in Python 2
??? I'm talking about modules removed now, in 2024. They were not deprecated since python2. Please don't steer the conversation to different topics.
> Lots of this stuff is just cruft, most of which has an obvious replacement
distutils? Is it cruft? The thing used to install modules? Can you tell me which stdlib replacement it has?
> it’s not been used in years by anyone
Why did I have to patch over 10 modules?
> and if it ever had a reason to be in the standard lib, that reason is long gone
Is installing modules no longer a thing then?
> those distro maintainers are harming everyone.
Aaah yes, the evil distro maintainers that keep things working instead of breaking everything. They're the real culprits here… really?
> I’ve written plenty of Python scripts that are still running on the interpreter and stdlib they were authored for, decades later.
Decades later? That's at least 20 years. If that were true they'd be written in python2 and I can promise you they wouldn't work with python 3.12. So I'll consider this statement a lie.
Please try to be more honest when you interact with me the next time. This hasn't been pleasant.
Used to be a viable strategy until they started to drop modules from the standard library at every single release.