On Wed, Nov 17, 2021 at 12:49 AM Terry Reedy <tjre...@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. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7WRG54YN5LFFXDBUCCFRQYHRSEMLVIO5/ Code of Conduct: http://python.org/psf/codeofconduct/
