[issue11610] Improving property to accept abstract methods

[Benjamin Peterson]

Benjamin Peterson <benjamin at python.org> added the comment:

Okay: how about this. We retain the passing of @abstractmethod to
abstractpropert(), but @abstractgetter decorates the method for you.

2011/5/14 Darren Dale <report at bugs.python.org>:
>
> Darren Dale <dsdale24 at gmail.com> added the comment:
>
> On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <benjamin at python.org> added the comment:
>>
>> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>>
>>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>>
>>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
>>> <report at bugs.python.org> wrote:
>>>>
>>>> Benjamin Peterson <benjamin at 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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________