←back to thread

Deprecations via warnings don't work for Python libraries

(sethmlarson.dev)
45 points scolby33 | 5 comments | 08 Dec 25 18:13 UTC | HN request time: 0s | source
Show context
theamk ◴[08 Dec 25 18:24 UTC] No.46195792[source]▶
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.

replies(8): >>46196064 #>>46197215 #>>46203939 #>>46220846 #>>46221176 #>>46221435 #>>46221650 #>>46221723 #
Hizonner ◴[10 Dec 25 18:26 UTC] No.46221435[source]▶
If you are a good developer, you consider warnings to be errors until proven otherwise.
replies(1): >>46221912 #
1. hiq ◴[10 Dec 25 18:58 UTC] No.46221912[source]▶
What does a good developer do when working in a codebase with hundreds of warnings?

Or are you only considering a certain warnings?

replies(1): >>46222489 #
2. Hizonner ◴[10 Dec 25 19:34 UTC] No.46222489[source]▶
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...
replies(3): >>46224192 #>>46224495 #>>46224683 #
3. stackskipton ◴[10 Dec 25 21:33 UTC] No.46224192[source]▶
Because most people are working at Failure/Feature factories where they might work on something and at last minute, they find out something is now warning. If they work on fixing it, the PM will screaming about time slippage and be like "I want you to work on X, not Y which can wait".

2 Years later, you have hundreds of warning.

4. hiq ◴[10 Dec 25 22:00 UTC] No.46224495[source]▶
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.

5. michaelt ◴[10 Dec 25 22:15 UTC] No.46224683[source]▶
> Why does your codebase generate hundreds of warnings

Well, it wasn't my codebase yesterday, because I didn't work here.

Today I do. When I build, I get reports of "pkg_resources is deprecated as an API" and "Tesla T4 does not support bfloat16 compilation natively" and "warning: skip creation of /usr/share/man/man1/open.1.gz because associated file /usr/share/man/man1/xdg-open.1.gz (of link group open) doesn't exist" and "datetime.utcnow() is deprecated and scheduled for removal in a future version"

The person onboarding me tells me those warnings are because of "dependencies" and that I should ignore them.