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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/
>
> 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-leave@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/