Message135989
| 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 |
<BANLkTikTbK1AQy-1+veV=VTvvxk6yroAdA@mail.gmail.com> |
| In-reply-to |
<1305404893.74.0.286298060695.issue11610@psf.upfronthosting.co.za> |
| Content |
On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin@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 |
|