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

61–70 of 93 posts

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

#61

Post by hiq »

Hizonner wrote: post #44
hiq wrote: post #41

Earlier quoted context omitted.

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

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.

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

#62

Post by minitech »

shadowgovt wrote: post #60
minitech wrote: post #46

Earlier quoted context omitted.

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.

> A breaking change in a dependency doesn’t cause a full-stop to a service at all From the article: "We still received feedback from users that this removal was unexpected and was breaking dependent libraries." I think we may be assuming different floors on service maintainer competency; with so many users pulling in dependencies across an arbitrarily-wide version window with no testing, such changes do break service…

It’s not necessary to cater to the absolute least competent end user to begin with, but inserting slowdown bugs does not even achieve that. (Note that the bit about the breaking of dependent libraries you’re quoting is still not actually a service being affected.)

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

#63

Post by michaelt »

Hizonner wrote: post #44
hiq wrote: post #41

Earlier quoted context omitted.

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

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

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

#64

Post by mxey »

integralid wrote: post #12
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?

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.

It’s like 5 lines of code https://github.com/urllib3/urllib3/pull/3732/files

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

#65

Post by bigstrat2003 »

Honestly, I think that the author already found (and rejected the solution):

> I could ask for more Python developers to run with warnings enabled, but solutions in the form of “if only we could all just” are a folly.

I get where he's coming from. But the facts are: the language provides a tool to warn users, the library is using that tool, and users are choosing to turn that tool off. That's fine, but then they don't get to complain when stuff breaks without warning. It is the user's responsibility at that point, not the library maintainers'.

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

#66

Post by stubish »

traverseda wrote: post #7

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.

They article does validly point out that deprecation warnings don't work. Turns out in this day and age that the only thing you can reliably inform about changes is the package manager and its dependency solver, and pip requires semver or similar for that.

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

#67

Post by eglintondust »

gsnedders wrote: post #53
plantain wrote: post #49

# Deprecated APIs resp.getheader("Content-Length") # Recommended APIs resp.headers.get("Content-Length") Why inflict this change on tens of millions of users? It's such a nonsense tiny busywork change. Let sleeping dogs lie.

This is exactly the sort of breaking change that I really struggle to see the value of — maintaining the deprecated method seems incredibly unlikely to be a notable maintenance burden when it is literally just: @deprecated("Use response.headers.get(name) instead") def getheader(self, name): return self.headers.get(name) Like sure — deprecate it, which might have _some_ downstream cost, rather than having two non-depr…

There is value for the person maintaining this library cause they want it that way. If you develop a useful library and give it away for free then all power to you if you want to rearrange the furniture every 6 months. I'll roll with it.

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

#68

Post by BugsJustFindMe »

traverseda wrote: post #7

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.

The value of semver has always been a lie. https://news.ycombinator.com/item?id=37426532

Making you distrust updates is absolutely the correct versioning method. Pin your versions in software you care about and establish a maintenance schedule. Trusting that people don't break things unintentionally all the time is extremely naive.

It was dumb and user-hostile to remove an interface for no good reason that just makes it more work for people to update, but everyone not pinning versions needs to acknowledge that they're choosing to live dangerously.

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

#69

Post by [deleted] »

tgsovlerkhgsel wrote: post #57

Deprecations don't work. Don't deprecate stuff without a really really good reason. The new API being cleaner is not a good reason. There are very few good reasons. If you deprecate something in a popular library, you're forcing millions of people to do work. Waste time that could be used for something better, possibly at a time of your choice, not theirs. It was emitting warnings for 3 years... so you think everyone…

[deleted]

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

#70

Post by somat »

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.

Just break, then revert when anyone complains, on every single release. eventually you will get a release where nobody complains as they move off the depreciated api due to breakage annoyance.
Post reply on HN