Live data from Hacker News

Deprecations via warnings don't work for Python libraries

sethmlarson.dev

11–20 of 93 posts

Re: Deprecations via warnings don't work for Python libraries

#11
post #2

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'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed.

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');
This is dead simple code in most testing frameworks. It makes maintaining and working with the test suite becomes much easier as when something starts behaving differently it's immediately obvious rather than being hidden in a sea of noise. It makes working with dependencies easier because it forces you to acknowledge things like deprecation warnings when they get introduced and either solve them there or create an upgrade plan.

Re: Deprecations via warnings don't work for Python libraries

#12
post #6

>We ended up adding the APIs back and creating a hurried release to fix the issue. So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?

OS software maintainers don't like maintaining legacy ugly APIs forever and want to refactor/remove legacy code to keep themselves sane and the project maintainable.

Re: Deprecations via warnings don't work for Python libraries

#13
post #2

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.

Why is it that CI tools don't make warnings visible? Why are they ignored by default in the first place? Seems like that should be a rather high priority.

It isn't that easy. If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit. Or you might still want to support a really old version without the new API and so you can't fix it now.

Re: Deprecations via warnings don't work for Python libraries

#15

Wait, does urlib not use semvar? Don't remove APIs on minor releases people. A major release doesn't have to be a problem or a major redesign, you can do major release 400 for all I care, just don't break things on minor releases. Lots of things not using semvar that I always just assumed did.

[deleted]

Re: Deprecations via warnings don't work for Python libraries

#17
post #6

>We ended up adding the APIs back and creating a hurried release to fix the issue. So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?

OS software maintainers don't like maintaining legacy ugly APIs forever and want to refactor/remove legacy code to keep themselves sane and the project maintainable.

Yep. Or you can see it as, "This software doesn't really care about the users and their use cases. It prioritizes making things look pretty and easier on the dev side over maintaining functionality." Or in the worse but fairly common OSS case, CADT, but that doesn't seem to apply in this context.

Re: Deprecations via warnings don't work for Python libraries

#18
Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects. 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? Why going through the pain?

IMO telling "we deprecate now and let's see when we remove it" is counterproductive.

A better way: deprecate now and tell "in 12 (or 24?) months this WILL be removed".

After 12/24 months, cut a new semver-major release. People notice the semver-major through the dependency management tools at some point, an maybe they have a look at changelog.

If they don't, at some point they may want to use a new feature, and finally be incentivised to update.

If there's no incentive other than "do the right thing", it never gets done.

Having said that, I think LLMs are really going to help with chores like this, if e.g. deprecations and migration steps are well documented.

Alternative option: create a codemod CLI that fixes deprecations for the users, doing the right thing automatically. If migration is painless and quick, it's more likely people will do it.

Re: Deprecations via warnings don't work for Python libraries

#19
post #2

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.

When I update python version, python packages, container image, etc for a service, I take a quick look at CI output, in addition to the all the other checks I do (like a couple basic real-world-usage end-to-end usage tests), to "smoke test" whether something not caught by outright CI failure caused some subtle problem.

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/

Re: Deprecations via warnings don't work for Python libraries

#20
Deprecations in all forms are always a shitshow. There isn’t a particular pattern that “just works”. Anybody that tells you about one, best case scenario, it just worked for them because of their consumer/user not because of the method itself.

The best I have seen is a heavy handed in-editor strike through with warnings (assuming the code is actively being worked on) and even then it’s at best a 50/50 thing.

50% of the developers would feel that using an API with a strike through in the editor is wrong. And the other 50% will just say “I dunno, I copied it from there. What’s wrong with it??”

Post reply on HN