Deprecations via Warnings Don't Work for Python Libraries

In my opinion test suites should treat any output other than the reporter saying that a test passed as a test failure. In JavaScript I usually have part of my test harness record calls to the various console methods. At the end of each test it checks to see if any calls to those methods were made, and if they were it fails the tests and logs the output. Within tests if I expect or want some code to produce a message, I wrap the invocation of that code in a helper which requires two arguments: a function to call and an expected output. If the code doesn't output a matching message, doesn't output anything, or outputs something else then the helper throws and explains what went wrong. Otherwise it just returns the result of the called function:

  let result = silenceWarning(() => user.getV1ProfileId(), /getV1ProfileId has been deprecated/);
  expect(result).toBe('foo');

In hindsight it actually helped us, because in frustrations we ended up setting up our own Python package repo and started to pay more attention to our dependencies.

So, I do often see deprecation warnings in CI output, and fix them. Am I a bad developer?

I think the mistake here is making some warnings default-hidden. The developer who cares about the user running their the app in a terminal can add a line of code to suppress them for users, and be more aware of this whole topic as a result (and have it more evident near the entrypoint of the program, for later devs to see also).

I think that making warnings error or hidden removes warnings as a useful tool.

But this is an old argument: Who should see Python warnings? (2017) https://lwn.net/Articles/740804/

As an example, I always knew urllib3 as one of the foundational packages that Requests uses. And I was curious, what versions of urllib3 does Requests pull in?

Well, according to https://github.com/psf/requests/blob/main/setup.cfg, it's this:

    urllib3>=1.21.1,<3

So, it seems to me that even the Requests folks assumed urllib3 was using semver.

Glory to 0ver: https://0ver.org/

The industry has a solution for the exact problem the urllib is having (semver). Urllib just actively refuses to use it.

Otherwise, I'd say that's a very brave comment you are making.

... and the right answer to that is to make it entirely their problem.

> Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed?

In this case, the warnings said exactly what release would remove the API. Didn't help.

> Why going through the pain?

Because you're not a feckless irresponsible idiot? I don't think it's an accident that the projects they said didn't react were an overcomplicated and ill-designed management layer for an overcomplicated and ill-designed container system, a move-fast-and-break-things techbro company, and what looks to be a consolation project for the not-too-bright.

You probably get an extrea measure of that if you're operating in the Python ecosystem, which is culturally all about half-assed, 80-percent-right-we-hope approaches.

The right answer is to remove it when you say you're going to remove it, and let them pick up the pieces.

It also helps if you design your API right to begin with, of course. But this is Python we're talking about again.

The urllib3 package doesn't use SemVer.

    @deprecated("Use response.headers.get(name) instead")
    def getheader(self, name):
        return self.headers.get(name)

(I also don't hate the thought of having a `DeprecationWarning` subclass like `IndefiniteDeprecationWarning` to make it clear that there's no plan to remove the deprecated function, which can thus be ignored/be non-fatal in CI etc.)