> Why would it be "interesting"? I don't see any practical advantage, and as soon as you need any form of logic you have to rewrite, so why bother?
The advantage of having a declarative API for deprecations is tooling support. It is much easier to detect decorator application than to reliably infer whether a function/class emits (or raises) a DeprecationWarning. I started a similar thread [*] a few weeks ago, but have had no chance to reply properly since. Sergei [*]: https://mail.python.org/archives/list/python-ideas@python.org/thread/EABCXCALZFRDH7CKMUL4YHFBQFOBUWN7/ On Thu, Jul 29, 2021 at 3:59 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On Thu, 29 Jul 2021 at 15:39, Leonardo Freua > <leonardo.batista.fr...@gmail.com> wrote: > > > > Would it be interesting to create a @deprecated decorator to avoid > adding warnings.warn("deprecation message", DeprecationWarning, > stacklevel=2) in methods body? > > I don't see the value personally. > > > Using the decorator approach to indicate depreciation would make the > methods cleaner (leaving only their responsibilities in the body) and would > be easier to identify, as the cue would be close to the method signature > and not mixed with the logic inside the body. > > First line of the body vs line before the declaration doesn't feel > like it makes much difference to me. > > > in some cases it will still be necessary to put warnings.warn (..) > inside the body of functions/methods because of some message display > condition, or we could also express the message display condition in the > decorator in @deprecated itself. But it would be interesting to have the > possibility of not putting this inside the method body. Even the decorator > can come from the notices module. > > Why would it be "interesting"? I don't see any practical advantage, > and as soon as you need any form of logic you have to rewrite, so why > bother? > > If you want this to get support, I think you need to argue the > benefits far more than you have so far... > > > Example: > > > > (Before) > > > > def check_metadata(self): > > """Deprecated API.""" > > warn("distutils.command.register.check_metadata is deprecated, \ > > use the check command instead", PendingDeprecationWarning) > > check = self.distribution.get_command_obj('check') > > check.ensure_finalized() > > check.strict = self.strict > > check.restructuredtext = 1 > > check.run() > > > > (after) > > > > @deprecated("distutils.command.register.check_metadata is deprecated, \ > > use the check command instead") > > def check_metadata(self): > > """Deprecated API.""" > > check = self.distribution.get_command_obj('check') > > check.ensure_finalized() > > check.strict = self.strict > > check.restructuredtext = 1 > > check.run() > > TBH, the decorator version makes it harder to see the function signature. > > -1 from me, I'm afraid. > > Disclaimer: I've never actually deprecated an API in my own code, so > my objections are mainly theoretical. > > Paul > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/6O7WJ3MLF3WEQ6XR7HEZPM6OBUZVY4PU/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YAI2Y5S6AWYNGKUDALYSC5TK2374K7A3/ Code of Conduct: http://python.org/psf/codeofconduct/
