[Python-Dev] defaultdict proposal round three

Alex Martelli aleaxit at gmail.com
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



More information about the Python-Dev mailing list