This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dsdale24
Recipients Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, ncoghlan, ned.deily
Date 2011-05-14.22:18:47
SpamBayes Score 1.110223e-16
Marked as misclassified No
Message-id <>
In-reply-to <>
On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson
<> wrote:
> Benjamin Peterson <> 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 <>:
>> Darren Dale <> added the comment:
>> On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson
>> <> wrote:
>>> Benjamin Peterson <> added the comment:
>>> 2011/5/14 Darren Dale <>:
>>>> Darren Dale <> added the comment:
>>>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
>>>> <> wrote:
>>>>> Benjamin Peterson <> 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.
Date User Action Args
2011-05-14 22:18:48dsdale24setrecipients: + dsdale24, ncoghlan, benjamin.peterson, ned.deily, daniel.urban, Darren.Dale
2011-05-14 22:18:47dsdale24linkissue11610 messages
2011-05-14 22:18:47dsdale24create