On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin@python.org> added the comment:
>
> Okay: how about this. We retain the passing of @abstractmethod to
> abstractpropert(), but @abstractgetter decorates the method for you.

That can work, although I would advise against it. I find it strange
that we would use @abstractmethod sometimes and not others. If that is
what it takes to get the patch accepted, so be it. But since I don't
understand the motivation behind this approach, I won't be the one to
document the special cases of when @abstractmethod is required and
when it is not.

> 2011/5/14 Darren Dale <report@bugs.python.org>:
>>
>> Darren Dale <dsdale24@gmail.com> added the comment:
>>
>> On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson
>> <report@bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <benjamin@python.org> added the comment:
>>>
>>> 2011/5/14 Darren Dale <report@bugs.python.org>:
>>>>
>>>> Darren Dale <dsdale24@gmail.com> added the comment:
>>>>
>>>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
>>>> <report@bugs.python.org> wrote:
>>>>>
>>>>> Benjamin Peterson <benjamin@python.org> added the comment:
>>>>>
>>>>> I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).
>>>>
>>>> Right, but I explained why the redundancy is necessary in order to
>>>> preserve backwards compatibility. If the abstractproperty constructor
>>>> were changed to tag methods it receives as abstract, it would be a
>>>> backwards-incompatible change in behavior with potential consequences
>>>> for consumers of abstractproperty.
>>>
>>> I'm not suggesting that it tag methods it receives as abstract.
>>> @getter/setter/deleter would still act the same.
>>
>> I wasn't talking about @getter/setter/deleter. I tried to be clear
>> that I was talking about the abstractproperty() constructor. It
>> doesn't currently tag the methods it receives as abstract, and to
>> change this would be a backward incompatible change. Therefore,
>> @abstractmethod should be used to tag methods as abstract before
>> passing them to the abstractproperty() constructor, and the abc
>> documentation should be changed to reflect this.
>>
>>>> abstractproperty.abstract(getter/setter/deleter) could be implemented,
>>>> but it still wouldn't change the fact that if a getter/setter is
>>>> intended to be abstract, it needs to be decorated with @abstractmethod
>>>> before being passed to the abstractproperty() constructor.
>>>
>>> Why not? You could set the __abstractmethod__ attribute in abstractgetter().
>>
>> I was not talking about decorating before passing @abstractgetter. I
>> was talking about decorating before passing to the abstractproperty()
>> constructor.
>>
>>>> This is
>>>> true today in <=python-3.2: its not mentioned in the documentation,
>>>> but the behavior exists all the same.
>>>
>>>>
>>>> Properties are composite objects, their behavior is defined by it is
>>>> the setters/getters/deleters they receive. So its actually a very
>>>> conceptually clean solution to decorate a method with @abstractmethod,
>>>> and it fits really nicely with the rest of the abc module. Why does
>>>> abstractproperty need special abstract(setter/getter/deleter) methods,
>>>> when the existing methods combine with @abstractmethod in a clean way
>>>> to produce the exact same result? To save one line of code?
>>>
>>> I find it produces a rather unfortunate ordering dependency for the
>>> decorators which is hard to remember.
>>
>> Why is it difficult to remember that you need to tag a method as
>> abstract before passing it to the property?
>
> I don't think the common case should be passing things to
> abstractproperty(), rather using the decorator.

It definitely is a common case, and always will be. You can't begin
using abstractproperty.abstract(getter/setter/deleter) until you have
an abstract property, which requires passing a (potentially abstract)
method to the constructor.