[issue16267] order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)
New submission from Christopher the Magnificent: This may be an issue with the interpreter behavior or it may be a documentation issue. Note: I only selected Python 3.3 as the version, but it probably affects MANY other Python versions. Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "copyright", "credits" or "license()" for more information.
class abstractclassmethod(builtins.classmethod) | A decorator indicating abstract classmethods. | | Similar to abstractmethod. | | Usage: | | class C(metaclass=ABCMeta): | @abstractclassmethod | def my_abstract_classmethod(cls, ...): | ... | | 'abstractclassmethod' is deprecated. Use 'classmethod' with | 'abstractmethod' instead. . (et cetra) . .
Hopefully this is enough documentation to show what the issues is. If not, just chime in. :-) ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 173183 nosy: christopherthemagnificent, docs@python priority: normal severity: normal status: open title: order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use) type: behavior versions: Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Changes by Andrew Svetlov <andrew.svetlov@gmail.com>: ---------- nosy: +asvetlov _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Andrew Svetlov added the comment: I think better to fix code to make first sample also work. It can be done as special cases in abc.abstractmethod to process classmethod/staticmethod objects properly. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA@GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
R. David Murray added the comment: I've added the nosy list from issue 11610, in case complicating the implementation is seen as sub-optimal :) ---------- nosy: +Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, eric.araujo, eric.snow, ncoghlan, python-dev, r.david.murray, stutzbach _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Benjamin Peterson added the comment: I don't see why classmethod/staticmethod should be special cased if it doesn't work for other decorators. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Darren Dale added the comment: Quoting the documentation for abstractmethod: "When abstractmethod() is applied in combination with other method descriptors, it should be applied as the innermost decorator, as shown in the following usage examples:" The examples include staticmethod and classmethod. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Christopher the Magnificent added the comment: As Darren Dale pointed out, it looks like this is a (partial) documentation issue. I think it's plausible that someone like me, who has used abstractmethod by itself, would read the docs for abstractclassmethod and not re-read the docs on abstract method to know that he needs to put the one decorator first and other other second. Changing Python to make it indifferent to the order of classmethod and abstractmethod wouldn't be a bad idea if it isn't too hairy to implement, since it does not seem to be intuitive to me and probably others that the order of the decorators in this specific situation should matter. At bare minimum, I recommend that the documentation for abstractclassmethod and abstractstaticmethod should be updated to indicate not merely that abstractmethod and either classmethod or staticmethod should be used together, but IN WHICH ORDER they should be used, if it is decided to preserve the sensitivity to ordering. :-) ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Andrew Svetlov added the comment: After brief looking sources I figured out it can be solved by adding setters for __isabstractmethod__ to classmethod/staticmethod objects. It can be done, I'll try to make a patch. For property situation is worse: property is abstract if any of getter/setter/deleter is abstract. Which object attribute should be set for setting __isabstractmethod__ for property? We can make the rule: abstractmethod for classmethod/staticmethod/property should set descriptor as abstract, not functions behind it. I'm not sure is it true solution but I like to try to make a patch for that. Anyway, the patch for describing current behavior in the docs is welcome. ---------- stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Eric Snow added the comment: The catch is that when abstractmethod is the inner decorator, __isabstractmethod__ is set on the object that classmethod/staticmethod is wrapping. When abstractmethod is the outer decorator, __isabstractmethod__ is set on the resulting classmethod/staticmethod object instead. Unless there is some practical reason that the distinction matters, I'm +1 on letting __isabstractmethod__ be set on classmethods and staticmethods. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Darren Dale added the comment: There is a very practical reason, which was the whole point of issue11610. Descriptors are should declare themselves abstract when they are composed of abstract methods. If you have a property with an concrete getter but an abstract setter, the property should declare itself abstract until such time as it is provided a concrete setter. If we allow __isabstractmethod__ to be settable by @abstractmethod, it undermines the whole scheme of descriptors delegating their abstractedness to the methods of which they are composed. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Nick Coghlan added the comment: It took me a while to get my brain back up to speed with the full rationale behind the current design (mostly by rereading the multitude of comment on #11610). As Darren says, the main advantage of the current scheme is that the wrapper descriptors deliberately *don't* have any concept of abstract/non-abstract independent of the methods that make them up. So I think the main thing to do is change the documentation of the affected descriptors to be more explicit about the required order of the replacement decorators. Otherwise people are likely to map "abstractXmethod" to "@abstractmethod + @Xmethod" and write them in that order (which won't work). ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Andrew Svetlov added the comment: After trying to make patch I've realized — better to leave current behavior as is and change documentation only. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Roundup Robot added the comment: New changeset 3345afd6dc61 by Nick Coghlan in branch '3.3': Close issue #16267: better docs for @abstractmethod composition http://hg.python.org/cpython/rev/3345afd6dc61 New changeset be7202c38089 by Nick Coghlan in branch 'default': Merge from 3.3 (issue #16267) http://hg.python.org/cpython/rev/be7202c38089 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Changes by Nick Coghlan <ncoghlan@gmail.com>: ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Changes by Andrew Svetlov <andrew.svetlov@gmail.com>: ---------- nosy: +asvetlov _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Andrew Svetlov added the comment: I think better to fix code to make first sample also work. It can be done as special cases in abc.abstractmethod to process classmethod/staticmethod objects properly. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA@GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
R. David Murray added the comment: I've added the nosy list from issue 11610, in case complicating the implementation is seen as sub-optimal :) ---------- nosy: +Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, eric.araujo, eric.snow, ncoghlan, python-dev, r.david.murray, stutzbach _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Benjamin Peterson added the comment: I don't see why classmethod/staticmethod should be special cased if it doesn't work for other decorators. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Darren Dale added the comment: Quoting the documentation for abstractmethod: "When abstractmethod() is applied in combination with other method descriptors, it should be applied as the innermost decorator, as shown in the following usage examples:" The examples include staticmethod and classmethod. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Christopher the Magnificent added the comment: As Darren Dale pointed out, it looks like this is a (partial) documentation issue. I think it's plausible that someone like me, who has used abstractmethod by itself, would read the docs for abstractclassmethod and not re-read the docs on abstract method to know that he needs to put the one decorator first and other other second. Changing Python to make it indifferent to the order of classmethod and abstractmethod wouldn't be a bad idea if it isn't too hairy to implement, since it does not seem to be intuitive to me and probably others that the order of the decorators in this specific situation should matter. At bare minimum, I recommend that the documentation for abstractclassmethod and abstractstaticmethod should be updated to indicate not merely that abstractmethod and either classmethod or staticmethod should be used together, but IN WHICH ORDER they should be used, if it is decided to preserve the sensitivity to ordering. :-) ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Andrew Svetlov added the comment: After brief looking sources I figured out it can be solved by adding setters for __isabstractmethod__ to classmethod/staticmethod objects. It can be done, I'll try to make a patch. For property situation is worse: property is abstract if any of getter/setter/deleter is abstract. Which object attribute should be set for setting __isabstractmethod__ for property? We can make the rule: abstractmethod for classmethod/staticmethod/property should set descriptor as abstract, not functions behind it. I'm not sure is it true solution but I like to try to make a patch for that. Anyway, the patch for describing current behavior in the docs is welcome. ---------- stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Eric Snow added the comment: The catch is that when abstractmethod is the inner decorator, __isabstractmethod__ is set on the object that classmethod/staticmethod is wrapping. When abstractmethod is the outer decorator, __isabstractmethod__ is set on the resulting classmethod/staticmethod object instead. Unless there is some practical reason that the distinction matters, I'm +1 on letting __isabstractmethod__ be set on classmethods and staticmethods. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Darren Dale added the comment: There is a very practical reason, which was the whole point of issue11610. Descriptors are should declare themselves abstract when they are composed of abstract methods. If you have a property with an concrete getter but an abstract setter, the property should declare itself abstract until such time as it is provided a concrete setter. If we allow __isabstractmethod__ to be settable by @abstractmethod, it undermines the whole scheme of descriptors delegating their abstractedness to the methods of which they are composed. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Nick Coghlan added the comment: It took me a while to get my brain back up to speed with the full rationale behind the current design (mostly by rereading the multitude of comment on #11610). As Darren says, the main advantage of the current scheme is that the wrapper descriptors deliberately *don't* have any concept of abstract/non-abstract independent of the methods that make them up. So I think the main thing to do is change the documentation of the affected descriptors to be more explicit about the required order of the replacement decorators. Otherwise people are likely to map "abstractXmethod" to "@abstractmethod + @Xmethod" and write them in that order (which won't work). ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Andrew Svetlov added the comment: After trying to make patch I've realized — better to leave current behavior as is and change documentation only. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Roundup Robot added the comment: New changeset 3345afd6dc61 by Nick Coghlan in branch '3.3': Close issue #16267: better docs for @abstractmethod composition http://hg.python.org/cpython/rev/3345afd6dc61 New changeset be7202c38089 by Nick Coghlan in branch 'default': Merge from 3.3 (issue #16267) http://hg.python.org/cpython/rev/be7202c38089 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
Changes by Nick Coghlan <ncoghlan@gmail.com>: ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16267> _______________________________________
participants (9)
-
Andrew Svetlov -
Arfrever Frehtes Taifersar Arahesis
-
Benjamin Peterson
-
Christopher the Magnificent
-
Darren Dale
-
Eric Snow
-
Nick Coghlan
-
R. David Murray
-
Roundup Robot