On 11/16/2021 7:43 AM, Petr Viktorin wrote:
On 16. 11. 21 1:11, Brett Cannon wrote:
I think the key point with that approach is if you wanted to maximize your support across supported versions, this would mean there wouldn't be transition code except when the SC approves of a shorter deprecation. So a project would simply rely on the deprecated approach until they started work towards Python 3.13, at which point they drop support for the deprecated approach and cleanly switch over to the new approach as all versions of Python at that point will support the new approach as well.
That sounds like a reasonable minimum for minor cleanups -- breakage that doesn't block improvements.
The current 'two years' minimum (and SC exceptions) is, IMO, appropriate for changes that do block improvements -- e.g. if removing old Unicode APIs allows reorganizing the internals to get a x% speedup, it should be removed after the 2-years of warnings (*if* the speedup is also made in that version -- otherwise the removal can be postponed). Even better if there's some alternate API for the affected use cases which works on all supported Python versions.
I agree that the yearly releases make 2 releases with warnings a bit short. Remove when a distributed replacement works in all supported releases seems pretty sensible.
And then there are truly trivial removals like the "failUnless" or "SafeConfigParser" aliases. I don't see a good reason to remove those -- they could stay deprecated forever.
This part I do not agree with. In 3.10, there are 15 fail* and assert* aliases with a messy overlap pattern. https://docs.python.org/3/library/unittest.html#deprecated-aliases This is 15 unneeded names that appear in the doc, the index, vars(), dir(), TestCase.__dict__ listings, completion lists, etc. If not used, there is no need to keep them. If kept 'forever', they will be used, making unittest code harder to read. There was a recent proposal to add permanent _ aliases for all stdlib camelCase names: assert_equal, assert_true, etc. After Guido gave a strong No, the proposal was reduced to doing so for logging and unittest only. If permanent aliases are blessed as normal, the proposal will recur and it would be harder to say no. I expect that there would be disagreements as to what is trivial enough.
The only danger that API posed to users is that it might be removed in the future (and that will break their code), or that they'll get a warning or a linter nag.
Python is nearly 30 years old. I am really glad it is not burdened with 30 years of old names. I expect someone reading this may write some version of Python 50 years from now. I would not want they to have to read about names deprecated 60 years before such a time. -- Terry Jan Reedy