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.lebe...@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/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/
>
_______________________________________________
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/VNEM3JETYYX4R4RLBPD4X3GXMW7Q32F5/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to