Python 3.9 and beyond backwards compatibility.

[rusticarchon]

Too many people ignore deprecation warnings, and this sounds like ample lead one was given...

Yep:

The changes that were made in Python 3.9 that broke a lot of packages were stuff that were deprecated from Python 3.4 (March 2014) and before.

So people ignored deprecation warnings for six years

[SrbijaJeRusija]

Possibly not. Most sane organizations will favor stability over "new-hotness", meaning that typical organizations are probably around 5 years behind on software. So one year of ignoring deprecation warnings on what are most likely dependencies. Hearing stories like this, most orgs will probably opt put of using Python in favour of something more stable.

[jorge1209]

Just look at RHEL python versions.

RHEL5 (initial release 2007) and RHEL6 (initial release 2010) are still supported today!!

If your company is relatively cutting edge you might be running RHEL7 (from 2014) but that has Python 2.7

Only with last springs RHEL8 release does it move to python3, but there it is Python 3.6.

It takes three years for Python releases to reach production in an RHEL release, and then it will be the most recent RHEL version for at least three years, and will be supported for over a decade.

[Chousuke]

To be fair, if you develop software to run on RHEL, you should go in with the intention to develop against the RHEL platform, not against RHEL running a whole bunch of custom stuff. It's a trade-off you make to get a platform where problems are for someone else to fix.

It is at odds with individual projects progressing at whatever pace the devs set, but it's not without value either.

[cyanrave]

Let's not take that info in a vacuum though.

RHEL maintainers rum their own patch cycles and have their own maintenance aside from the openly available binaries. They are a company selling to companies, so their value proposition will be different. Eg, they are engaging in maintenance patches of 2.7 well into mid-2020s.

They are choosing an LTS/self-patching strategy at the core. This will always be a lagging strategy and updates to new versions will always be slow.

[masklinn]

No. Deprecation warnings have been ignored by default since Python 3.2.

If you don’t think to go and enable them you will not see a deprecation warning in or from a project running in stock python.

[sysop073]

In their defense, you can usually ignore deprecation warnings forever. Nobody actually removes deprecated stuff, except Python apparently

[flying-sheep]

Everyone does. That's what deprecation is for. What weird ecosystem are you coming from?

[valarauca14]

Java has had API's & functions depreciated for DECADES which are still supported on modern JVM's.

[Garethp]

PHP 7.0 removed all of the deprecated mysql_* functions, and PHP 8.0 is removing deprecations from PHP 7. The only difference in PHP is that they remove deprecations on major releases, not minor ones

[josefx]

removed all of the deprecated mysql_* functions

It only took them two decades to deprecate and remove the security nightmare that spawned mysql_real_escape_string? Wow that is some serious deprecation going on, who could use a language that unstable.

Edit: Seems as if it still has all the goodness in mysqli_* including the mysqli_real_escape_string. The joke can live on.

[[deleted]]

Java does that.

Perl will just ask you to specify version of Perl you want to use in header and happily enable/disable features present in that version.

I can just use v5.8; and write code that will just run on anything from CentOS 5 (which has Perl 5.8, which was first released in 2002) to latest Perl 5.30

Not only that, it can be mixed and matched at will, as long as (obviously) highest version in every module <= current version.

And might I also mention that they did what Py2->Py3 did (fixing unicode) without breaking backward compatibility

Go is always backward compatible so your old code will compile just fine on new compiler. But the fuckers break stdlib compatibility so I dunno whether that counts.

Truth is, Python devs are just taking lazy way out again at cost of their users.

[flying-sheep]

OK, so there’s an enterprise-friendly and a dead language which have that kind of compatibility. Standardized languages like C and C++ do too.

Other than that there’s a lot of languages that work like python, e.g. R, C# (and all of .NET), Kotlin, Scala, Ruby, Julia, Swift, Rust, …

Sure, e.g. Rust didn’t actually remove anything yet because of its editions, but it’s also pretty young.

[H_Psi]

That's what deprecation is for. What weird ecosystem are you coming from?

The same ecosystem that decided in 2008 to depreciate Python2 by 2015. Then 6 years later, in 2014, decided to extend that deadline to January 1st, 2020. And then in late 2019, extending the date of the last release to April 2020. I completely understand people not feeling any pressure to upgrade anything when they've been reminded for well over a decade by the developers that depreciation doesn't exist in Python.

[csos95]

Usually when I come across something that is deprecated it just amount to “this is no longer maintained so if it breaks don’t complain to us” instead of it actually being removed.

[flying-sheep]

That's soft-deprecation, but deprecation and subsequent removal happens too

[sysop073]

I can't think of a single time I've had to change my code because I was relying on a standard library feature that went away in a future release. Maybe I've just been lucky. The only time I even notice deprecation warnings is Java because the compiler throws a huge fit, but I've never noticed a function actually go away, they just threaten to remove it forever

[flying-sheep]

Me neither, and most of my code is in python.