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

71–80 of 93 posts

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

#71

Post by minitech »

somat wrote: post #51
CaliforniaKarl wrote: post #22

Earlier quoted context omitted.

This, I think, is the crux of the matter. As an example, I always knew urllib3 as one of the foundational packages that Requests uses. And I was curious, what versions of urllib3 does Requests pull in? Well, according to https://github.com/psf/requests/blob/main/setup.cfg , it's this: urllib3>=1.21.1, That is exactly the kind of dependency specification I would expect to see for a package that is using semver: The cu…

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.

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

#72

Post by Wowfunhappy »

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.

I definitely agree with the sentiment that people working for free can do whatever the heck they want.

But if you're trying to help your users and grow your project, I think GP's advice is sound.

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

#73

Post by minitech »

BugsJustFindMe wrote: post #68
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…

In practice, semver is very helpful. Its major benefit is allowing packages to declare compatibility with versions of their own dependencies that don’t exist yet. (Distrusting updates and pinning versions is important and correct, but it’s not a “versioning method” that stands in contrast to semver or anything. That’s what lockfiles are for.) The pre-semver Python package ecosystem is a good example of what happens without it: fresh installs of packages break all the time because they have open-ended or overly permissive upper bounds on their dependencies. If they were to specify exact preexisting upper bounds, they’d slow down bugfixes (and in Python, where you can only have one version of a package in a given environment, new features) and add maintenance busywork; I’m not aware of any packages that choose this option in practice.

> You have released version 1.0.0 of something. Then you add a feature and fix a bug unrelated to that feature. Are you at version 1.1.0 or 1.1.1? Well, it depends on the order you added your changes, doesn't it? If you fixed the bug first you'll go from 1.0.0 to 1.0.1 to 1.1.0, and if you add the feature first you'll go from 1.0.0 to 1.1.0 to 1.1.1. And if that difference doesn't matter, then the last digit doesn't matter.

It depends on the order you released your changes, yes. If you have the option, the most useful order is to release 1.0.1 with the bugfix and 1.1.0 with both changes, but you can also choose to release 1.1.0 without the bugfix (why intentionally release a buggy version?) and then 1.1.1 (with or without 1.0.1), or just 1.1.0 with both changes. You’re correct that the starting point of the patch version within a particular minor version doesn’t matter – you could pick 0, 1, or 31415. You can also increment it by whatever you want in practice. All this flexibility is a total non-problem (let alone a problem with the versioning scheme, considering it’s flexibility that comes from which releases you even choose to cut – semver just makes the relationship between them clear), and doesn’t indicate that the patch field is meaningless in general. (Obviously, you should start at 0 and increment by 1, since that’s boring and normal.)

Sure, it’s impossible to classify breaking changes and new features with perfect precision, and maintainers can make mistakes, but semver is pretty clearly a net positive. (It takes almost no effort and has no superior competitors, so it would be hard for it not to be.)

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

#74

Post by throwaway2046 »

JackSlateur wrote: post #56
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.

semver is funny because it gives the illusion of working but does not work at all Glory to 0ver: https://0ver.org/

Semver works fine for SDL and has worked fine since the start of the century, despite the library's complexity and scale. A few simple rules can go a long way if you're disciplined about enforcing them.

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

#75

Post by Hizonner »

hiq wrote: post #61
Hizonner wrote: post #44

Earlier quoted context omitted.

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…

> If I start working on an existing codebase, the warnings might be there already. Then what do I do?

What would you do if the code you inherited crashed all the time?

Come up with a strategy for fixing them steadily until they're gone.

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

#76

Post by Hizonner »

stackskipton wrote: post #55
Hizonner wrote: post #44

Earlier quoted context omitted.

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

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.

You found that out at the last minute. So then you did a release. It's no longer the last minute. Now what's your excuse for the next release?

If your management won't resource your project to the point where you can assure that the software is correct, you might want to see if you can find the free time to look for another job. You'll have to do that anyway when they either tank the company, or lay you off next time they feel they need to cut more costs.

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

#78

Post by Incipient »

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 number across the board - it makes it more consistent and error proof.

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

#79

Post by skeledrew »

philipwhiuk wrote: post #10
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.

Python itself doesn't use semver.

Because everyone is afraid of a v4, after the 2-3 debacle. And there are things which need to be culled every once in a while to keep the stdlib fresh.
Post reply on HN