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