[Python-Dev] defaultdict proposal round three

[Greg Ewing]

Guido van Rossum wrote:

> It's quite tricky to implement a fully
> transparent wrapper that supports all the special
 > methods (__setitem__ etc.).

I was thinking the wrapper would only be a means of
filling the dict -- it wouldn't even pretend to
implement the full dict interface. The only method
it would really need to have is __getitem__.

> The semantics of defaultdict are crystal clear. __contains__(), keys()
>  and friends represent the *actual*, *current* keys.

If you're happy with that, then I am too. I was
never particularly attached to the wrapper idea --
I just mentioned it as a possible alternative.

Just one more thing -- have you made a final decision
about the name yet? I'd still prefer something like
'autodict', because to me 'defaultdict' suggests
a type that just returns default values without modifying
the dict. Maybe it should be reserved for some possible
future type that behaves that way.

Also, considering the intended use cases (accumulation,
etc.) it seems more accurate to think of the value
produced by the factory as an 'initial value' rather
than a 'default value', and I'd prefer to see it
described that way in the docs. If that is done,
having 'default' in the name wouldn't be so appropriate.

Greg