Victor Stinner writes:
In Python, usually, there is a better alternative.
As in life.
Do you have to repeat "You should check for DeprecationWarning in your code" in every "What's New in Python X.Y?" document?
That probably doesn't hurt, but I doubt it does much good for anybody except the bewildered first-day college intern who wonders why nobody in the devops team follows best practices. They'll learn to ignore those lines pretty quick, too, I'm sure. ;-) What I think would make a difference is a six-like tool for making "easy changes" like substituting aliases and maybe marking other stuff that requires human brains to make the right changes. I'm not volunteering to do this, I don't even know that it's actually feasible. But I think that unless we're willing to bite that bullet, it's going to be difficult to make much progress over the current situation. Deprecated code does normally more or less work, and often it never gets close to dangerous behavior. On the flip side, it often can cause dangerous behavior, and you won't know if it does until you do a thorough audit of your use case, which isn't going to happen because it would take as much effort as replacing the deprecated code. I think we all see both sides, even if our own individual experience leads us to want to change the current balance. Unfortunately, as we see here, some folks want more removals, some peole want less (or none).