[Python-Dev] deprecation of abstractstaticmethod and abstractclassmethod

[Nathaniel Smith]

I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.

On Wed, May 15, 2019, 12:39 Ethan Furman <ethan at stoneleaf.us> wrote:

> In issue 11610* abstractclassmethod and abstractstaticmethod were
> deprecated, apparently because they were redundant with the new technique
> of calling `classmethod` or `staticmethod` followed by a call to
> `abstractmethod`.  To put it in code:
>
> # deprecated
>
> class Foo(ABC):
>
>      @abstractclassmethod
>      def foo_happens(cls):
>          # do some fooey stuff
>
> # the new(er) way
>
> class Foo(ABC):
>
>      @classmethod
>      @abstractmethod
>      def foo_happens(cls):
>          # do some fooey stuff
>
>
> I would like to remove the deprecated status of `abstractclassmethod` and
> `abstractstaticmethod` mainly because:
>
> - using the combined decorator is easy to get right
>    (@abstractmethod followed by @classmethod doesn't work)
>
> - getting the order wrong can be hard to spot and fix
>
> Obviously, decorator order matters for many, if not most, decorators out
> there -- so why should these two be any different?  Because 'abstract',
> 'class', and 'static' are adjectives -- they're describing the method,
> rather than changing it**; to use an example, what is the difference
> between "hot, dry sand" and "dry, hot sand"?  The sand is just as dry and
> just as hot either way.  In a debugging session looking at:
>
>     @abstractmethod
>     @classmethod
>     def some_func(self, this, that, the_other):
>          # many
>          # many
>          ...
>          ...
>          ...
>          # many
>          # lines
>          # of
>          # code
>
> Not noticing that the two decorators are in reverse order would be very
> easy to do.
>
> Because order matters here, but cognitively should not, a helper function
> to make sure it is always done right is a prime candidate to be added to a
> module -- and, luckily for us, those helper functions already exist!
> Unfortunately, they are also deprecated, discouraging their use, when we
> should be encouraging their use.
>
> What are the reasons to /not/ remove the deprecation?
>
> --
> ~Ethan~
>
>
>
> * https://bugs.python.org/issue11610
>
> ** I realize that abstractmethod does actually change the function, but
> that's an implementation detail.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/njs%40pobox.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190515/8a048814/attachment-0001.html>