Perhaps another approach would be to make a more general purpose warning decorator, that would give a warning when invoking a function or instantiating a class. It could be used for deprecation notices, of course, but has the potential for tooling to give other types of warnings, such as using a thread unsafe call in a threading context. On Thu, Jul 29, 2021 at 14:26 Sergei Lebedev <sergei.a.lebedev@gmail.com> wrote:
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/EABCXCA...
On Thu, Jul 29, 2021 at 3:59 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Thu, 29 Jul 2021 at 15:39, Leonardo Freua <leonardo.batista.freua@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-leave@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/6O7WJ3... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/YAI2Y5... Code of Conduct: http://python.org/psf/codeofconduct/