On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
> 2011/3/29 Darren Dale <report@bugs.python.org>:
>> 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.

Did you read the documentation I provided in the patch? There is no
asymmetry, the documentation and examples provided by previous python
releases are demonstrably inadequate. For example:

class AbstractFoo(metaclass=ABCMeta):
    def get_bar(self): ...
    def set_bar(self, val): ...
    bar = abstractproperty(get_bar, set_bar)

The documentation indicates that a subclass will not be instantiable
until all of its abstract methods and properties are overridden. What
is abstract about the bar property? Was it the getter, setter, or
both, or neither? The answer is neither. A subclass can simply do:

class Foo(AbstractFoo):
    bar = property(AbstractFoo.get_bar, AbstractFoo.set_bar)

and it is instantiable. On the other hand, for AbstractFoo to assert
that subclasses must provide concrete implementations of the get_bar
and set_bar methods, it must decorate get_bar and set_bar with
@abstractproperty. This is true for previous releases of python, the
documentation of abstractproperty in previous python releases is
simply incomplete. If a method is abstract, it needs to have an
__isabstractmethod__ attribute that is True, and @abstractmethod
provides the means of setting this attribute.

This patch simply extends abstractproperty so it can respect the
abstractedness of the methods assigned to it. If somebody defines an
ambiguous abstractproperty like my AbstractFoo example, they get the
same result with the patch as they did without: an abstract property
with two concrete methods (this is an unfortunate situation that
cannot be fixed without breaking backwards compatibility).

Therefore, there is no asymmetry between when @abstractmethod is
required and when it is not. If the *method* is abstract and must be
reimplemented by a subclass, @abstractmethod is required. Even for
methods that participate in property definitions, even with
<=python-3.2.

>> 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.

I think you misunderstood my point. I agreed with you that it could be
tagged by @abstractgetter. It cannot be tagged by the constructor.
That is where an asymmetry would be introduced between when
@abstractmethod is needed (declare methods abstract before passing
them to the constructor) and when it would not be (passing methods to
abstractgetter which declares them abstract).

(By the way, in review of issue11610.patch, GVR said he thought I had
the right idea and that the backward compatibility goal was satisfied.
Some of these points were covered in that discussion.)

Darren