On Thu, 29 Jul 2021 at 16:00, Paul Moore email@example.com wrote:
On Thu, 29 Jul 2021 at 15:39, Leonardo Freua firstname.lastname@example.org 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.
I do see the value. Many projects use this kind of functionality and end up reinventing something along these lines e.g.: https://github.com/scipy/scipy/blob/6bc0b7297aaca7c7c1b4854d421b20d35172222c...
Actually deprecating functions and methods is probably the easiest part. You can either emit a warning from inside the function or use a deprecator to do the same when the function is called. That does mean though that there's no programmatic way to know without calling the function that it is deprecated.
Other cases are deprecating e.g. a class, or a particular instance/object or a module. If a module is deprecated you can trigger a warning on import but of course import caching means that subsequent imports won't see the warning (maybe that's okay...). For an object you might want to use __getattr__ to trigger the warning. Then difficulty comes if introspective tools use getattr, dir etc so users end up seeing the warning even though nothing is actually using the deprecated functionality: https://github.com/sympy/sympy/issues/9371
This is the kind of thing that is on the edge of being worth a PyPI dependency: do you really want to have an external dependency just to give out warnings for stuff that you wish wasn't in your codebase in the first place?
Not needing to reinvent the wheel in many projects is useful but actually the real advantages of standardising deprecation as I see it are things like:
1. If there is a standardised attribute like __deprecated__ then introspective tools can avoid triggering the warning. 2. Static/introspective analysis could determine if deprecated functionality is potentially being used even if e.g. the function does not happen to be called during the test suite. 3. The attribute could expose useful information in a standardised way like version_deprecated, version_will_be_removed, use_instead, url_for_more_information etc so that smart editors and other tooling can check this (perhaps in tandem with checking a requirements.txt or something).