Deprecations via warnings don't work for Python libraries • Hacker News Board

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

#91

Post by minitech » Thu, Dec 11, 2025, 9:21 PM UTC

minitech wrote: post #71

somat wrote: post #51

Earlier quoted context omitted.

I would almost expect the 3 in urllib3 to be the major version and if something needed to break it would become urllib4. Which, I know, is terribly naive of me. But that is how psycopg does it.

That was how psycopg2 did it, but now the package is psycopg (again) version 3, as it should be. Python package management has come a long way since psycopg 1 was created. urllib2/3’s etymology is different: urllib2’s name comes from urllib in the standard library.

er, *urllib3’s name comes from urllib2 in the standard library.

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

#92

Post by gsnedders » Sat, Dec 13, 2025, 11:52 PM UTC

eglintondust wrote: post #67

gsnedders wrote: post #53

Earlier quoted context omitted.

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.

You are, of course, correct.

But the fact that they made a new release with it undeprecated shows they _do_ care about their users (direct and indirect), and at least from my point of view (both from the Python ecosystem and the browser ecosystem) this was a pretty foreseeable outcome.

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

#93

Post by Incipient » Mon, Dec 15, 2025, 9:21 AM UTC

BugsJustFindMe wrote: post #88

Incipient wrote: post #78

I'm very confused on the debate of semver here - the fundamental principle seems very simple, and important. "give me all updates to my core version that's still compatible" Semver simply puts a 'protocol' to this - define your major version and off you go. While in practice you could go and search for each and every library you use to check when/how they do breaking versions, but semver just allows matching a single…

Because it's not "error proof". It's not even "more error proof". Relying on updates not breaking if the maintainer doesn’t intend it means relying on software being bug-free, and it should be immediately obvious that that would be a very very stupid thing to believe. Letting software you rely on change on its own is always dangerous no matter how much someone pinky promises that you can trust them to have thought of…

I would absolutely agree with your approach for large-scale saas/highly publicised applications, especially when you have a team/people dedicated to security/versioning.

In small teams where you're focused on building features, being able to rely on semver for non-breaking versions has been very helpful/successful. I personally haven't encountered a breaking feature added to something that shouldn't be.

This also applies to our docker containers, using python 3.13-slim-trixie for example, and letting the patch version sort itself out.