-
There's a builtin exception for this, it's called NotImplementedError
-
I find abstract methods to be useful as documentation tools -- you can give a method signature and docstring, without an implementation. But it only happens in a certain style of programming, typically one with lots of subclassing and a framework sort of feel. I find subclassing a little questionable, but it works out sometimes.
-
I thought of using NotImplementedError, but seeing that name always gives me the impression that something is *going* to be implemented, it just isn't there yet. :-)
In fact, I wonder if there are people who use it like that...
-
A strange premise really, wanting to call a superclass's method without knowing what it does. But hey, it happens...
I don't find it so strange. I frequently use classes provided by someone else (a library writer, my coworkers, etc). Occasionally that someone else is a skilled OOP programmer and the way to "use" the class is to subclass it. Frequently, I'm lazy (or, more likely, too busy) to read the code. So I don't know what the superclass method does, but I know that I'm supposed to call it (__init__() is an excellent example).
-
I fairly frequently do exactly what is suggested in the first example above: raise an exception in the abstract method.
In my code, an abstract base class is frequently used to document an interface. I don't feel a need for anything as fancy as Ivo's idea.
-
"""I don't find it so strange. I frequently use classes provided by someone else. [...] Frequently, I'm lazy (or, more likely, too busy) to read the code. So I don't know what the superclass method does, but I know that I'm supposed to call it (__init__() is an excellent example)."""
Understandable, especially in the case of __init__. But without knowing *anything* about it? For regular methods, I think that you'd at least need to know what it returns (if anything).