How about "pure virtual methods"?

[Nick Coghlan]

John Machin wrote:
> 6. Alex's magnum opus appears to operate on problem a, and maybe on b
> (it's over my head). It involves a fair chunk of mucking about -- for
> what? Early warning, a few microseconds ahead of the invocation of a
> method which will cause the stub in the base class to raise an
> exception?

Alex eats metaclasses for breakfast though, so while it may look like a magnum 
opus to mere mortals, it is in reality nothing more than an idle twiddle :)

Anyway, I see two major problems with the OP's idea:

1. It encourages laziness when subclassing
   Subclassing necessarily involves intimate coupling of code. If you don't 
understand the base class well enough to know which methods you are required to 
implement, and haven't even included those methods in your unit tests. . . then 
I'm willing to bet those missing methods are the least of your worries when it 
comes to correct operation of your class.

2. It gives up some of the dynamism of Python
   The OP's idea denies the inheritor the ability to partially implement the 
defined interface. Sometimes, particularly for objects used for a very specific 
purpose, it makes sense to only implement the portion of an interface that you 
want to use. The standard method makes it easy to flag a portion of the 
interface as off limits - just leave it raising a Not Implemented exception. 
With the OP's idea in place, the inheritor is forced to implement the entirety 
of the interface, even if they only need a fraction of it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net