deprecation of abstractstaticmethod and abstractclassmethod
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.
participants (5)
-
Antoine Pitrou
-
Ethan Furman
-
Nathaniel Smith
-
Nick Coghlan
-
Steve Dower