Instead of reverting the updates to appease those who've been ignoring the warnings, a way forward could be to gate the old API behind an environment variable, with a name like "TEMPORARILY_REENABLE_DEPRECATED_APIS". And maybe put an expiry on the variable so it resets occasionally. Otherwise the project just becomes mired and stagnant.
Deprecations via warnings don't work for Python libraries
81–90 of 93 posts
Re: Deprecations via warnings don't work for Python libraries
#82Deprecations 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.
That's why you, very early on, release code that slows the API down once it has been deprecated. Every place you issue a deprecation warning, you also sleep 60. Problem solved.
A solid idea. There should be a package for this.
Re: Deprecations via warnings don't work for Python libraries
#83The 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.
I think it's more likely that they move off the broken library due to breakage annoyance.
Re: Deprecations via warnings don't work for Python libraries
#84Earlier quoted context omitted.
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.
Python is culling stuff all the time, but that doesn't warrant a major version jump.
You are probably right about Pythons careful approach of when to ship v4, but for the wrong reasons. Python 3 was necessary not for the removal of functions, but because of the syntax changes e.g., moving print from a statement to a method.
Re: Deprecations via warnings don't work for Python libraries
#85Earlier quoted context omitted.
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.
If this code crashed all the time there'd be a business need to fix it and I could justify spending time on this.
But that's not what we're discussing here, we're discussing warnings that have been ignored in the past, and all of a sudden I'm supposed to take the political risk to fix them all somehow, even though there's no new crash, no new information.
I don't know how much freedom you have at your job; but I definitely can't just go to my manager and say: "I'm spending the next few weeks working on warnings nobody else cared about but that for some reason I care about".
Re: Deprecations via warnings don't work for Python libraries
#86Earlier quoted context omitted.
This will just waste CI compute and not solve anything.
It's worked in the past. But it does require someone at your org to care that CI times are spiking, which is not always a thing you can rely upon. In addition: if CI is the only place the issue shows up, and never in a user interaction... Why does that software exist in the first place? In that context, the slowdown may be serving as a useful signal to the project to drop the entire dependency. ETA : To be clear, I d…
Most CI runs I see have more than a 10s variance.
Re: Deprecations via warnings don't work for Python libraries
#87Deprecations 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…
Open source developers have no such obligation. They’re doing things on their own time. But hey, I’m sure they’d be willing to give you a full refund for the amount you paid them to use their work
Re: Deprecations via warnings don't work for Python libraries
#88I'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 everything. Semver numbers are determined by humans who aren't oracles and therefore make mistakes all the time about what changes will break something for someone else. It may get people to think a little bit about whether they _think_ they're breaking something, but it's never safe to rely on that judgement because there's a good chance that they're wrong. And given that it's never safe to rely on that judgment, the process of pretending is worse than worthless; the pretense is inherently dangerous, because people start to unthinkingly trust it. If you care about things working, you pin and vendor (npm left-pad) your dependencies and only update a package if you _need_ to and only after explicit evaluation.
And if after reading that you think to yourself, "But BugsJustFindMe, I have unit tests that will catch semver mistakes!" I think you need to ask yourself what your unit tests tell you about semver code that they don't also tell you about non-semver code.
Re: Deprecations via warnings don't work for Python libraries
#89Earlier 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.
> 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.
That would make it no longer a useful library
Re: Deprecations via warnings don't work for Python libraries
#90I prefer Go's solution to this problem. Just don't deprecate stuff. And to make that possible, slow down and design stuff you will be willing to support forever.
Go does deprecate stuff. It just never removes it.