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 <et...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/njs%40pobox.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com