callable virtual method

[Scott David Daniels]

Jean-Michel Pichavant wrote:
> Steven D'Aprano wrote:
>> On Fri, 14 Aug 2009 18:49:26 +0200, Jean-Michel Pichavant wrote:
>>
>>  
>>> Sorry guys (means guys *and* gals :op ), I realized I've not been able
>>> to describe precisely what I want to do. I'd like the base class to be
>>> virtual (aka abstract). However it may be abstract but it does not mean
>>> it cannot do some usefull stuff.
>>>
>>>
>>> Here is the schema of my abstract methods :
>>>
>>> class Interface(object):
>>>     def method(self):
>>>         # ---------------------
>>>         # some common stuff executed here
>>>         # ---------------------
>>>         print 'hello world'
>>>         # ---------------------
>>>         # here shall stand child specific stuff (empty in the interface
>>> method)
>>>         # ---------------------
>>>         if self.__class__.method == Interface.method:
>>>             raise NotImplementedError('You should have read the f******
>>> manual ! You must override this method.')
>>>     
>>
>>
>> Okay, so I want to sub-class your Interface class. As you said, the 
>> methods in the abstract class are still useful, so in my class, I 
>> don't need any extra functionality for some methods -- I'm happy with 
>> just the "common stuff". So I use normal OO techniques and over-ride 
>> just the methods I need to over-ride:
>>
>>   
> Sometimes the base is doing cool stuff but incomplete stuff which 
> requires knowledge only hold by the sub class. In my case the interface 
> is a high level interface for a software that can run on multiple 
> hardware platforms. Only the sub class has knowledge on how to operate 
> the hardware, but no matter the hardware it still produces the same effect.
> 
> Let's say I have 50 different hardwares, I'll have 50 sub classes of 
> Interface with the 'start' method to define. It wouldn't be appropriate 
> (OO programming)to write 50 times '_log.debug('Starting %s' % self)' in 
> each child start method when the simple task of logging the call can be 
> nicely handled by the base class.
> 
> In the meantime, I must make sure  the user, who is not a python guru in 
> this case, has implemented the start method for his hardware, because 
> only him knows how to effectively start this hardware. I don't want him 
> to come to me saying, "I got no error, still my hardware does not 
> start". You can then blame him for not reading the docs, but it will 
> still be less expensive to throw a nice exception with an accurate 
> feedback.
> 
> [snip]
>> class VerboseGoodChild(Interface):
>>     # forced to over-ride methods for no good reason
>>   
> 
> Definitely no !! This is the purpose of an interface class: to force 
> people to write these methods. They *are* required, if they were not, 
> they would not belong to the Interface.
> 
> JM

But there _is_ one moment when you can check those things, then avoid
checking thereafter: object creation.  So you can complicate your
__init__ (or __new__) with those checks that make sure you instantiate
only fully defined subclasses:

# obviously not tested except in concept:

     class Base(object_or_whatever):
          def __init__(self, ...):
              class_ = self.__class__
              if class_ is Base:
                  raise TypeError('Attempt to instantiate Base class')
              for name in 'one two three four':
                  if getattr(Base, name) is not getattr(Base, name):
                      raise NotImplementedError(
                                  '%s implementation missing' % name)
              ...

--Scott David Daniels
Scott.Daniels at Acm.Org