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 benjamin.peterson
Recipients Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, ncoghlan, ned.deily
Date 2011-05-14.22:24:11
SpamBayes Score 2.503008e-07
Marked as misclassified No
Message-id <>
In-reply-to <>
2011/5/14 Darren Dale <>:
> Darren Dale <> added the comment:
> On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson
> <> wrote:
>> Benjamin Peterson <> 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.

It would just be a convenience.

> 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.

What about

def something(): pass

def set(): pass

def delete: pass

requires you to pass a method (explicitly) to a constructor?
Date User Action Args
2011-05-14 22:24:12benjamin.petersonsetrecipients: + benjamin.peterson, ncoghlan, ned.deily, daniel.urban, dsdale24, Darren.Dale
2011-05-14 22:24:11benjamin.petersonlinkissue11610 messages
2011-05-14 22:24:11benjamin.petersoncreate