On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
<[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/6O7WJ3MLF3WEQ6XR7HEZPM6OBUZVY4PU/
Code of Conduct: http://python.org/psf/codeofconduct/