Author ncoghlan
Recipients Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, eric.araujo, eric.snow, michael.foord, ncoghlan, stutzbach
Date 2011-06-12.00:09:09
SpamBayes Score 3.34871e-10
Marked as misclassified No
Message-id <1307837350.5.0.377928137309.issue11610@psf.upfronthosting.co.za>
In-reply-to
Content
Remember the goal here is *not* to completely eliminate the need to test that objects implement an ABC correctly. It's to make it easier to declare the expected interface in a way that helps readers of the ABC definition to figure out what is going on, and to reduce the proliferation of abstract descriptors.

Since we made a deliberate choice not to do signature checks when ABCs were added to the language, there's nothing an ABC can do to stop someone (for example) overriding an abstract method or descriptor "foo" with "foo = 1". That's almost certainly wrong, but it's wrong at a level that ABCs don't care about.

If someone incorrectly overrides a read/write property with a read-only property and there's nothing in their test suite that picks that up, then that's a flaw in the test suite, not a flaw in the ABC itself.

Regarding the naming, @abstractmethod and __isabstractmethod__ are definitely about methods, or method-based descriptors (such as property). There *could* be a case to be made to allow for abstract data attributes, but really, using an abstract property should cover that use case well enough.
History
Date User Action Args
2011-06-12 00:09:10ncoghlansetrecipients: + ncoghlan, benjamin.peterson, stutzbach, eric.araujo, michael.foord, daniel.urban, dsdale24, eric.snow, Darren.Dale
2011-06-12 00:09:10ncoghlansetmessageid: <1307837350.5.0.377928137309.issue11610@psf.upfronthosting.co.za>
2011-06-12 00:09:09ncoghlanlinkissue11610 messages
2011-06-12 00:09:09ncoghlancreate