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.21:04:55
SpamBayes Score 1.1690399e-10
Marked as misclassified No
Message-id <>
In-reply-to <>
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.
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. 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?

Date User Action Args
2011-05-14 21:05:05dsdale24setrecipients: + dsdale24, ncoghlan, benjamin.peterson, ned.deily, daniel.urban, Darren.Dale
2011-05-14 21:04:55dsdale24linkissue11610 messages
2011-05-14 21:04:55dsdale24create