2011/3/29 Darren Dale <report@bugs.python.org>:
>
> Darren Dale <dsdale24@gmail.com> added the comment:
>
> I see some problems with this approach, but maybe I haven't fully appreciated it. Let me summarize the goals and constraints as I see them:
>
> 1) compatible with long-form and decorator syntax of {abstract}property declaration
> 2) backwards compatible, no change in semantics/behavior
> 3) decorator syntax needs to yield a concrete property once all abstract methods associated with the abstract property have been replaced with concrete implementations. (This is the reason why each abstract method associated with the property needs to get tagged with __isabstractmethod__. It provides an accounting of abstract methods associated with the property which fits with the existing semantics of abstract method declaration.)
>
> The current approach actually satisfies all of the goals and constraints. It fits well with the existing semantics, there are no surprises and no changes in behavior for any existing code. It is even compatible with anyone who may have used @abstractmethod to decorate methods destined to be passed to @abstractproperty using the long-form property declaration (which would have worked even though it was not documented!)
>
> The benefit of abstractproperty.abstract{...} is that one decorator is required instead of two, right? Are there others?

Mostly it doesn't create a weird asymmetry between a @abstractproperty
decorated function not needing @abstractmethod but
@someabstractprop.setter needing it.

>
> It is true that one could define abstract{getter,setter,deleter} decorators that would take care of setting the __isabstractmethod__ attribute on the function received, so that the @abstractmethod decorator would not be needed *once the property has been created*.
>
> But if @abstractmethod is discouraged in favor of abstractproperty.abstractgetter and friends, abstractproperty would have to tag each method passed to its constructor as abstract (in order to support the long-form syntax and also the initial declaration with the decorator syntax) which would actually be a change in behavior with potential consequences. For example, maybe a third party defined a concrete getter in an abstract base class, and python-3.3 can't instantiate the subclasses because that getter was automatically tagged as abstract by the new abstractproperty constructor. So @abstractmethod would still be needed for methods passed to the constructor, meaning sometimes @abstractmethod would be needed, and sometimes it would not.

That's not true. The method could be tagged in @abstractgetter decorator.