Darren Dale <dsdal...@gmail.com> added the comment: On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson <rep...@bugs.python.org> wrote: > > 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.
That can work, although I would advise against it. I find it strange that we would use @abstractmethod sometimes and not others. If that is what it takes to get the patch accepted, so be it. But since I don't understand the motivation behind this approach, I won't be the one to document the special cases of when @abstractmethod is required and when it is not. > 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. It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. ---------- _______________________________________ 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
