Style for overwritten methods of abstract classes

Graham Ashton graz at
Thu Jan 3 16:50:45 EST 2002

In article <3C34A6AE.4293E82C at>, "Stefan Schwarzer"
<s.schwarzer at> 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()" % \


More information about the Python-list mailing list