Darren Dale <dsdal...@gmail.com> added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson <rep...@bugs.python.org> wrote: > > Benjamin Peterson <benja...@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. 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? Darren ---------- _______________________________________ 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
