Darren Dale <dsdal...@gmail.com> added the comment:
On Tue, Mar 29, 2011 at 10:24 PM, Darren Dale <rep...@bugs.python.org> wrote:
>
> Darren Dale <dsdal...@gmail.com> added the comment:
>
> On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
> <rep...@bugs.python.org> wrote:
>> 2011/3/29 Darren Dale <rep...@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.
Sorry, that should have read @abstractmethod.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
