From afar, Python 3.x releases seem more like major updates than point releases. There’s entirely blocks of functionality/syntax between 3.x releases.

Except it is mostly additive.

Adding new features will seldom break old stuff. It is the removing part that is hard.

(With the exception being when like a variable broke because it became a keyword, but if you made a variable something like async I am not sure you are entirely innocent).

You're supposed to pay attention to DeprecationWarnings.

The problem is that the entire ecosystem needs to pay attention to such warnings and it doesn't happen. As a result, these changes end up breaking code in places the program authors never touched.

That's true in one respect, but you as an end user can use them to know not to upgrade before your deps have changed what they need to.

What? You upgrade your dependencies when there's a feature or improvement you need. Not because they don't have some warnings. Who cares?

The old version you implicitly claim is better isn't, it just doesn't have the warnings from their dependencies in place yet.

I mean, if you're going to upgrade your python version, you should check your logs to see if you have had any DWs recently. If you have, upgrade your deps before upgrading python. If theres no new version available, you can't upgrade python yet.

In my experience DeprecationWarnings get turned off so frequently because I'm not forking big library to fix all of it's Deprecated uses of their dependencies.

The warnings are useless if they're not from my code, so they get turned off once globally.

They are still important. Because even if dependency has this warning, it will still break your code.

but they are also not actionable

You can file an issue/PR in most cases, and if you don't get a response you may need to worry about moving libraries.

well actually they are, they essentially saying that in future version your application will break.

Yes, it is not your package that is responsible, but it still affects your application, you could open a ticket, or submit a PR. If you had that message you should also hold of with upgrading to newer python until this is resolved.

> well actually they are, they essentially saying that in future version your application will break.

No, you idiot. It's a deprecated usage in a dependency.

What happens in the future is I update pandas, it stops using the deprecated numpy method, and the warning just disappears with very little action on my part.

It's a useless warning.

And submit a PR every time this happens? How about I request you pull me?

> If you had that message you should also hold of with upgrading to newer python until this is resolved.

1. Upgrading to newer python? Who fucking cares

2. Upgrading resolves the warning entirely.

"The function time.clock() has been removed, after having been deprecated since Python 3.3"

Python 3.3 was release in 2012. You've had 8 years.

Well, technically we already moved to 3.8, after which needed a library that only works up until 3.7.

It would be nice if library developers kept their code up to date, but that doesn't always happen. Python core devs know this; well all know this, yet they consciously screw with the core libraries with the principle, caveat emptor.

I don't understand why they don't ear-mark these changes for 4.0. These kind of things are a universal frustration with the community and they are so easily avoidable.

What difference would it make whether the change had been called 3.8 or 4.0?

I'm confused, who exactly has had 8 years to do what? Should he have dumped the crypto module because it was using a deprecated feature?

The reason the crypto module was using this particular deprecated feature is that it hasn't been updated at all in 8 years.

The OP should have dropped it because it's unmaintained, and a maintained replacement has existed for a long time: https://cryptography.io/

This is an especially important consideration for security-critical libraries like cryptographic libraries.

See, when you explain what's wrong it's so much better than just blaming the victim with "You've had 8 years"!

One issue the ecosystem currently has, really (and its not the only one, I believe it's difficult almost everywhere), is that tracking dependency-rot is hard. Unless something breaks outright, you'll never know if a library has been abandoned; and manually checking dozens of github/gitlab repos is expensive and tedious.

Pypi has an api (https://pypi.org/pypi/<pkg-name>/json) that can be leveraged to implement alerts like "this pkg last released 5 years ago, it might be dead!". I guess that's what the "security" package uses already. It would be cool if they added an option to report on this sort of thing.

OP here, thanks a bunch for this! I will take your advice and dump the crypto library for this one.

this is text from maual:

> Deprecated since version 3.3, will be removed in version 3.8: The behaviour of this function depends on the platform: use perf_counter() or process_time() instead, depending on your requirements, to have a well defined behaviour.

I would be wary of any crypto library that continued to work with a warning for 8 years and no one bothered to fix it. Most likely no one was maintaining it.

Perl does it as well, but then you've only got point releases because it's stuck at 5.

I think at this point they should jump to perl7 and resume normal versioning