My long post gives all the philosophy, but I'll give here the short answers.
Mike Meyer wrote:
+0
Python doesn't use classes for typing. As Alex Martelli puts it, Python uses protocols. So the client expecting a concrete subclass of your abstract class may get an instantiation of a class that doesn't inherit from the abstract class at all.
That's right - this mechanism is useful mostly for he who implements that class, to make sure that he implemented all that is needed to be assigned the title "a subclass of that class".
I disagree - my reasoning is that a subclass must implement the complete interface of its base class (see my long post). The author may implement a class which defines only a part of the interface, and give it to the function, and it may work and be great. But it must not be called "an instance of the abstract class".
Or maybe the subclass is only going to use a subset of the features of the abstract class, and the author knows that sum deferred methods won't be invoked. The correct behavior in this case would be to allow the subclass to be instantiated, and then get a runtime error if one of the features the author thought he could skip was actually called.
Finally, in a sufficiently complex class hierarchy, this still leaves you wondering through the hierarchy trying to find the appropriate parent class that tagged this method as unimplemented, and then figuring out which class should have implemented it - as possibly a parent of the class whose instantiation failed is the subclass that should have made this method concrete.
You are right - but I needed this for a class hierarchy of only two levels (the base abstract class and the concrete subclasses), so there were not many classes to blame for a missing method.
<mike
I hope this seems reasonable, Noam -- http://mail.python.org/mailman/listinfo/python-list
