title: Subclassing dict: should dict.__init__() be called?
body: <p>Here is a twofold question, with a theoretical part, and a practical one:</p>
  
  <p>When subclassing dict:</p>
  
  <pre><code>class ImageDB(dict):
      def __init__(self, directory):
          dict.__init__(self)  # Necessary?? 
          ...
  </code></pre>
  
  <p>should <code>dict.__init__(self)</code> be called, just as a "safety" measure (e.g., in case there are some non-trivial implementation details that matter)?  is there a risk that the code break with a future version of Python if <code>dict.__init__()</code> is <em>not</em> called?  I'm looking for a fundamental reason of doing one thing or the other, here (practically, calling <code>dict.__init__()</code> is safe).</p>
  
  <p>My guess is that when <code>ImageDB.__init__(self, directory)</code> is called, self is already a new empty dict object, and that there is therefore no need to call <code>dict.__init__</code> (I do want the dict to be empty, at first).  Is this correct?</p>
  
  <p><strong>Edit</strong>:</p>
  
  <p>The more practical question behind the fundamental question above is the following.  I was thinking of subclassing dict because I would use the db[…] syntax quite often (instead of doing db.contents[…] all the time); the object's only data (attribute) is indeed really a dict.  I want to add a few methods to the database (such as <code>get_image_by_name()</code>, or <code>get_image_by_code()</code>, for instance), and only override the <code>__init__()</code>, because the image database is defined by the directory that contains it.</p>
  
  <p><strong>In summary</strong>, the (practical) question could be: what is a good implementation for something that behaves like a dictionary, except that its initialization is different (it only takes a directory name), and that it has additional methods?</p>
  
  <p>"Factories" were mentioned in many answers.  So I guess it all boils down to: do you subclass dict, override <code>__init__()</code> and add methods, or do you write a (factory) function that returns a dict, to which you add methods?  I'm inclined to prefer the first solution, because the factory function returns an object whose type does not indicate that it has additional semantics and methods, but what do you think?</p>
  
  <p><strong>Edit 2</strong>:</p>
  
  <p>I gather from everybody's answer that it is not a good idea to subclass dict when the new class "is not a dictionary", and in particular when its <code>__init__</code> method cannot take the same arguments as dict's <code>__init__</code> (which is the case in the "practical question" above).  In other words, if I understand correctly, the consensus seems to be: when you subclass, all methods (including initialization) must have the same signature as the base class methods.  This allows isinstance(subclass_instance, dict) to guarantee that <code>subclass_instance.__init__()</code> can be used like <code>dict.__init__()</code>, for instance.</p>
  
  <p>Another practical question then pops up: how should a class which is just like dict, except for its initialization method, be implemented?  without subclassing?  this would require some bothersome boilerplate code, no?</p>