How about "pure virtual methods"?

[Noam Raphael]

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

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

> 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