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 benjamin.peterson, daniel.urban, dsdale24, ncoghlan, ned.deily
Date 2011-03-30.02:25:57
SpamBayes Score 7.228107e-11
Marked as misclassified No
Message-id <>
In-reply-to <>
On Tue, Mar 29, 2011 at 10:24 PM, Darren Dale <> wrote:
> Darren Dale <> added the comment:
> On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
> <> wrote:
>> 2011/3/29 Darren Dale <>:
>>> 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.
Date User Action Args
2011-03-30 02:25:58dsdale24setrecipients: + dsdale24, ncoghlan, benjamin.peterson, ned.deily, daniel.urban
2011-03-30 02:25:57dsdale24linkissue11610 messages
2011-03-30 02:25:57dsdale24create