On Wed, Nov 17, 2021 at 12:49 AM Terry Reedy <tjreedy@udel.edu> wrote:
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.
Well, dir(), vars(), __dict__ and similar are already unpleasant -- ever since they started listing dunder methods, quite a long time ago. But we could improve completion, docs and other cases that can filter the list. How about adding a __deprecated__ attribute with a list of names that tab completion should skip?
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.
If they dedicated section is too distracting. they could be moved to a subpage, reachable mainly by people searching for a particular name. And the instructions on how to modernize code could be right next to them.