Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deprecations via warnings don't work for Python libraries

sethmlarson.dev

Post reply on HN
Print view View original

31–40 of 93 posts

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

#31

Post by shadowgovt »

memco wrote: post #27
superkuh wrote: 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?

I think this is a valid question for this specific case, but may not always be possible. That said, I think as a user I would probably prefer it if under the hood the old function called the new so they can deprecate the behavior without breaking the API. In that way you can still emit the deprecation warning while also only having one actual code path to maintain.

Funny enough, in Python, a sufficiently-dedicated client can also do this on their end by just monkey-patching the class definition.

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

#32

Post by mrweasel »

theamk wrote: 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.

There was this one library we depended on, it was sort of in limbo during the Python 2 -> 3 migration. During that period is was maintained by this one person who'd just delete older versions when never ones became available. In one year I think we had three or four instances where our CI and unit tests just broke randomly one day, because the APIs had changed and the old version of the library had been yanked.

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.

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

#33

Post by ipaddr »

CaliforniaKarl wrote: post #21
hartator wrote: post #14

I think they are misreading the situation. The devil is in the details. It seems `getHeaders` v. `headers` is non-security, non-performance related issue. Why people should spend time fixing these?

If you (either directly or from SerpApi) are supporting the urllib3 folks (through a Tidelift subscription), then yes, that is a valid point. Otherwise, I'd say that's a very brave comment you are making.

If he gave money valid point if not he must be brave?

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

#34

Post by bluGill »

Hizonner wrote: post #28
bluGill wrote: post #13

Earlier quoted context omitted.

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.

> 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. So you create a bug report or an issue or a story or whatever you happen to call it, and you make sure it gets tracked, and you schedule it with the rest of your work. That's not the same thing as "ignoring" it.

And you always have something more important/interesting to do and so never get around to it.

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

#35

Post by Hizonner »

bluGill wrote: post #34
Hizonner wrote: post #28

Earlier quoted context omitted.

> 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. So you create a bug report or an issue or a story or whatever you happen to call it, and you make sure it gets tracked, and you schedule it with the rest of your work. That's not the same thing as "ignoring" it.

And you always have something more important/interesting to do and so never get around to it.

... which means that when the axe falls, the results are 100 percent your fault.

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

#36

Post by wang_li »

theamk wrote: 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.

That's why you, very early on, release code that slows the API down once it has been deprecated. Every place you issue a deprecation warning, you also sleep 60. Problem solved.

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

#37

Post by odie5533 »

shadowgovt wrote: post #29

The secret trick I've used on rare occasion, but when necessary, is the "ten second rule." Users don't notice a deprecation warning. But they might notice adding a "time.sleep(10)" immediately at the top of the function. And that gives them one last grace period to change out their software before it breaks-breaks.

This will just waste CI compute and not solve anything.

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

#38

Post by shadowgovt »

odie5533 wrote: post #37
shadowgovt wrote: post #29

The secret trick I've used on rare occasion, but when necessary, is the "ten second rule." Users don't notice a deprecation warning. But they might notice adding a "time.sleep(10)" immediately at the top of the function. And that gives them one last grace period to change out their software before it breaks-breaks.

This will just waste CI compute and not solve anything.

It's worked in the past. But it does require someone at your org to care that CI times are spiking, which is not always a thing you can rely upon.

In addition: if CI is the only place the issue shows up, and never in a user interaction... Why does that software exist in the first place? In that context, the slowdown may be serving as a useful signal to the project to drop the entire dependency.

ETA: To be clear, I don't do this as a substitute for a regular deprecation cycle (clear documentation, clear language-supported warnings / annotations, clear timeline to deprecate); I do it in addition before the final yank that actually breaks end-users.

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

#39

Post by hiq »

Wild (and I guess most of the time bad) idea: on top of the warnings, introduce a `sleep` in the deprecated functions. At every version, increase the sleep.

Has this ever been considered?

The problem with warnings is that they're not really observable: few people actually read these logs, most of the time. Making the deprecation observable means annoying the library users. The question is then: what's the smallest annoyance we can come up with, so that they still have a look?

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

#40

Post by Hackbraten »

A deprecation warning is not actionable for typical end users. Why don't more warnings include calls to action?

Instead of a warning that says, "The get_widget method in libfoo is deprecated and will be removed by November 30", the warning could say:

"This app uses the deprecated get_widget method. Please report this bug to the app developer. Ask them to fix this issue so you can continue using this app after November 30."

Post reply on HN