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

41–50 of 93 posts

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

#41

Post by hiq »

Hizonner wrote: post #25
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.

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?

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

#42

Post by pavel_lishin »

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.

Are you saying you wouldn't notice if your CI suddenly started taking twice as long, ten times as long, a hundred times as long to run?

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

#43

Post by minitech »

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 is so much worse than just making the breaking change.

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

#44

Post by Hizonner »

hiq wrote: post #41
Hizonner wrote: post #25

Earlier quoted context omitted.

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...

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

#45

Post by shadowgovt »

minitech wrote: post #43
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 is so much worse than just making the breaking change.

It depends on how we define "worse."

A breaking change causes a full-stop to a service.

An intentional slowdown lets the service continue to operate at degraded performance.

I concur that it's less clear for debugging purposes (although any reasonable debugging infrastructure should allow you to break and see what function you're in when the program hangs; definitely not as clear as the program crashing because the called function is gone, however).

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

#46

Post by minitech »

shadowgovt wrote: post #45
minitech wrote: post #43

Earlier quoted context omitted.

This is so much worse than just making the breaking change.

It depends on how we define "worse." A breaking change causes a full-stop to a service. An intentional slowdown lets the service continue to operate at degraded performance. I concur that it's less clear for debugging purposes (although any reasonable debugging infrastructure should allow you to break and see what function you're in when the program hangs; definitely not as clear as the program crashing because the c…

A breaking change in a dependency doesn’t cause a full-stop to a service at all. The old version continues to work. Making subtly harmful changes so that new broken versions sneak in is just a bad idea and totally unnecessary.

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

#48

Post by fpoling »

hiq wrote: post #39

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 an…

Yes, people do notice sleep. But it has to be on the scale of minutes or it will be ignored especially if it happens during a CI run.
Post reply on HN