Author dsdale24
Recipients Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, eric.araujo, michael.foord, ncoghlan, stutzbach
Date 2011-06-11.16:54:26
SpamBayes Score 4.96978e-06
Marked as misclassified No
Message-id <BANLkTinh_uRdZSXf6edUAaUxRuWeaLvxXw@mail.gmail.com>
In-reply-to <1307796917.62.0.113519414273.issue11610@psf.upfronthosting.co.za>
Content
[...]
>
> This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists.

I think there is another reason to do it this way. Suppose I have a
custom descriptor MyProperty that stores its getter as
MyProperty.my_fget. In this example:

class C:
    @property
    @abstractmethod
    def foo(self): return 1

class D:
    @MyProperty
    def foo(self): return 2

if ABCMeta determines C.foo.fget is abstract, it will not recognize
that D.foo.my_fget supplies the concrete implementation. MyProperty
may provide the same interface as property, it may even subclass
property, but there is no guarantee its implementation conforms to
property the way ABCMeta is expecting it to.

The downside to making __isabstractmethod__ a property is that if C
declares foo to be a read/write property, and D redefines foo as
read-only and concrete, ABCMeta will not recognize the oversight. That
seems a significant deficiency to me. I'm not sure how to proceed.

Darren
History
Date User Action Args
2011-06-11 16:54:27dsdale24setrecipients: + dsdale24, ncoghlan, benjamin.peterson, stutzbach, eric.araujo, michael.foord, daniel.urban, Darren.Dale
2011-06-11 16:54:27dsdale24linkissue11610 messages
2011-06-11 16:54:26dsdale24create