[Python-Dev] defaultdict proposal round three

Mon Feb 20 17:05:11 CET 2006

On Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote:
 ...
> Alternative A: add a new method to the dict type with the semantics of
> __getattr__ from the last proposal, using default_factory if not None
> (except on_missing is inlined). This avoids the discussion about
> broken invariants, but one could argue that it adds to an already
> overly broad API.
>> Alternative B: provide a dict subclass that implements the __getattr__
> semantics from the last proposal. It could be an unrelated type for
> all I care, but I do care about implementation inheritance since it
> should perform just as well as an unmodified dict object, and that's
> hard to do without sharing implementation (copying would be worse).

"Let's do both!"...;-). Add a method X to dict as per A _and_ 
provide in collections a subclass of dict that sets __getattr__ to X 
and also takes the value of default_dict as the first mandatory 
argument to __init__.
Yes, mapping is a "fat interface", chock full of convenience methods, 
but that's what makes it OK to add another, when it's really 
convenient; and nearly nobody's been arguing against defaultdict, 
only about the details of its architecture, so the convenience of 
this X can be taken as established. As long as DictMixin changes 
accordingly, the downsides are small.
Also having a collections.defaultdict as well as method X would be my 
preference, for even more convenience.
 From my POV, either or both of these additions would be an 
improvement wrt 2.4 (as would most of the other alternatives debated 
here), but I'm keen to have _some_ alternative get in, rather than 
all being blocked out of 2.5 by "analysis paralysis".
Alex