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