Deprecations via warnings don't work for Python libraries

Deprecations via warnings don't reliably work anywhere, in general.

If you are a good developer, you'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed.

If you are a bad developer, you have no idea what you are doing and you ignore all warnings unless program crashes.

If you are a good developer, you consider warnings to be errors until proven otherwise.

What does a good developer do when working in a codebase with hundreds of warnings?

Or are you only considering a certain warnings?

Why does your codebase generate hundreds of warnings, given that every time one initially appeared, you should have stamped it out (or specifically marked that one warning to be ignored)? Start with one line of code that doesn't generate a warning. Add a second line of code that doesn't generate a warning...

It's rare that I work on a project I myself started. If I start working on an existing codebase, the warnings might be there already. Then what do I do?

I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all?

But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.

> If I start working on an existing codebase, the warnings might be there already. Then what do I do?

What would you do if the code you inherited crashed all the time?

Come up with a strategy for fixing them steadily until they're gone.