[Python-Dev] deprecation of abstractstaticmethod and abstractclassmethod (original) (raw)

Ethan Furman ethan at stoneleaf.us
Wed May 15 15:37:55 EDT 2019

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:

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

** I realize that abstractmethod does actually change the function, but that's an implementation detail.

More information about the Python-Dev mailing list