Title: order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)
Type: behavior Stage: resolved
Components: Documentation, Interpreter Core Versions: Python 3.4, Python 3.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Arfrever, Darren.Dale, asvetlov, benjamin.peterson, christopherthemagnificent, daniel.urban, docs@python, dsdale24, eric.araujo, eric.snow, ncoghlan, python-dev, r.david.murray, stutzbach
Priority: normal Keywords:

Created on 2012-10-17 15:41 by christopherthemagnificent, last changed 2012-12-09 05:01 by ncoghlan. This issue is now closed.

Messages (12)
msg173183 - (view) Author: Christopher the Magnificent (christopherthemagnificent) Date: 2012-10-17 15:41
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.
>>> import abc
>>> help(abc.abstractclassmethod)
Help on class abstractclassmethod in module abc:

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)
>>> # doesn't work
>>> class Demo(metaclass=abc.ABCMeta):
... 	@abc.abstractmethod
... 	@classmethod
... 	def test(cls):
... 		pass
Traceback (most recent call last):
  File "<pyshell#26>", line 1, in <module>
    class Demo3(metaclass=abc.ABCMeta):
  File "<pyshell#26>", line 3, in Demo3
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/", line 24, in abstractmethod
    funcobj.__isabstractmethod__ = True
AttributeError: attribute '__isabstractmethod__' of 'classmethod' objects is not writable
>>> # DOES work
>>> class Demo2(metaclass=abc.ABCMeta):
... 	@classmethod
... 	@abc.abstractmethod
... 	def test(cls):
... 		pass
>>> Demo2()
Traceback (most recent call last):
  File "<pyshell#33>", line 1, in <module>
TypeError: Can't instantiate abstract class Demo2 with abstract methods test

Hopefully this is enough documentation to show what the issues is.  If not, just chime in.  :-)
msg173184 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-10-17 16:40
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.
msg173188 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-10-17 17:47
I've added the nosy list from issue 11610, in case complicating the implementation is seen as sub-optimal :)
msg173189 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2012-10-17 18:07
I don't see why classmethod/staticmethod should be special cased if it doesn't work for other decorators.
msg173190 - (view) Author: Darren Dale (dsdale24) Date: 2012-10-17 18:15
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.
msg173198 - (view) Author: Christopher the Magnificent (christopherthemagnificent) Date: 2012-10-17 19:26
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.

msg173200 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-10-17 20:00
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.
msg173280 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-10-18 15:54
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.
msg173282 - (view) Author: Darren Dale (Darren.Dale) Date: 2012-10-18 16:32
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.
msg175417 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-11-12 02:53
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).
msg176823 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-12-03 00:42
After trying to make patch I've realized — better to leave current behavior as is and change documentation only.
msg177159 - (view) Author: Roundup Robot (python-dev) Date: 2012-12-08 12:57
New changeset 3345afd6dc61 by Nick Coghlan in branch '3.3':
Close issue #16267: better docs for @abstractmethod composition

New changeset be7202c38089 by Nick Coghlan in branch 'default':
Merge from 3.3 (issue #16267)
Date User Action Args
2012-12-09 05:01:11ncoghlansetstatus: open -> closed
resolution: fixed
stage: needs patch -> resolved
2012-12-08 12:57:33python-devsetmessages: + msg177159
2012-12-03 00:42:06asvetlovsetmessages: + msg176823
2012-11-12 02:53:16ncoghlansetmessages: + msg175417
2012-10-18 16:32:17Darren.Dalesetmessages: + msg173282
2012-10-18 15:54:40eric.snowsetmessages: + msg173280
2012-10-17 20:00:19asvetlovsetstage: needs patch
messages: + msg173200
versions: + Python 3.4
2012-10-17 19:26:45christopherthemagnificentsetmessages: + msg173198
2012-10-17 18:15:10dsdale24setmessages: + msg173190
2012-10-17 18:07:00benjamin.petersonsetmessages: + msg173189
2012-10-17 17:47:51r.david.murraysetnosy: + stutzbach, dsdale24, python-dev, eric.snow, ncoghlan, daniel.urban, eric.araujo, Darren.Dale, r.david.murray, benjamin.peterson
messages: + msg173188
2012-10-17 17:02:10Arfreversetnosy: + Arfrever
2012-10-17 16:40:26asvetlovsetmessages: + msg173184
2012-10-17 16:33:48asvetlovsetnosy: + asvetlov
2012-10-17 15:41:20christopherthemagnificentcreate