Style for overwritten methods of abstract classes

[Graham Ashton]

In article <3C34A6AE.4293E82C at ndh.net>, "Stefan Schwarzer"
<s.schwarzer at ndh.net> wrote:

> class CacheBase:
>     '''Represents an abstract interface for the URL/value storage.
>     
>     Overwrite __init__, __getitem__, __setitem__, and __del__ to
>     customize the class.'''
> 
>     def __init__(self):
>         pass
> 
>     def __getitem__(self, url):
>         '''Return an abstract value from the cache for the given URL.
>         Return None if the URL is not in the cache.''' return None
> [snip]

I suspect that what you've got above is only a little more useful than
documentation on it's own. Atleast it's more likely to get updated if the
interface changes. Whenever I need to do this I always go for your third
option (raise an exception).

I also tend to use that trick when I'm fleshing out an interface and think
I'm being too lazy to write all my unit tests up front; it's like an extra
safety net, even if I don't need to overwrite stuff later. A bit like an
in-line post-it note, telling me exactly where to come back to implement
the next bit of functionality.

> 3. use code but let the abstract methods raise NotImplementedError
>    instead of providing a default behaviour which might be useless

I also like it to tell me exactly what was missed (okay, you can find it
in the traceback, but I find this slows down my edit/run cycle less):

  def spam(self):
      raise NotImplementedError, "%s has not implemented spam()" % \
	                         self.__class__

--- 
Graham