←back to thread

Deprecations via warnings don't work for Python libraries

(sethmlarson.dev)
45 points scolby33 | 2 comments | 08 Dec 25 18:13 UTC | HN request time: 0.385s | source
Show context
superkuh ◴[10 Dec 25 17:03 UTC] No.46220253[source]▶
>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?

replies(2): >>46220931 #>>46221520 #
1. memco ◴[10 Dec 25 18:31 UTC] No.46221520[source]▶
I think this is a valid question for this specific case, but may not always be possible. That said, I think as a user I would probably prefer it if under the hood the old function called the new so they can deprecate the behavior without breaking the API. In that way you can still emit the deprecation warning while also only having one actual code path to maintain.
replies(1): >>46221621 #
2. shadowgovt ◴[10 Dec 25 18:39 UTC] No.46221621[source]▶
Funny enough, in Python, a sufficiently-dedicated client can also do this on their end by just monkey-patching the class definition.