Deprecations via warnings don't work for Python libraries

Posted by birdculture 3 days ago

Counter8Comment3OpenOriginal

Comments

Comment by Lammy 3 days ago

Deprecation warning and eventual removal makes sense for cases where the replacement follows some different programming pattern, like different arguments or different return types, but this particular deprecation appears to be merely a different way of accessing the exact same thing. The diff to add it back in was a seven-line change: https://github.com/urllib3/urllib3/pull/3732/files#diff-008f...

Was it really worth trying to force developers' hands over this in the first place? I doubt users care about the naming purity of the library code. Sure, remove it from the documentation so new users only see the preferred new way, but I would be annoyed if I used this library and had to go around renaming a bunch of call sites just to satisfy upstream's ideological purity drive.

Comment by cpburns2009 3 days ago

> DeprecationWarning is called out in the “ignored by default” list for Python.

Wait, what!? Python suppresses those by default? That makes it completely useless. That's what I use in my open source libraries.

Comment by zahlman 3 days ago

Yep. Same reason people keep getting taken off guard by Setuptools breaking changes, even though they follow semver. (Of course, it's often not their fault that they upgraded, thanks to isolated build environment systems.)

> Warning categories that are primarily of interest to Python developers (rather than end users of applications written in Python) are ignored by default.

The idea is that the person running the application shouldn't see cryptic messages at runtime because the application developer didn't respond to the deprecation. But you know, maybe they should. Best way to put pressure on that developer is to get user issue reports.