Pre-PEP: Dictionary accumulator methods - typing & initialising

Kay Schluehr kay.schluehr at
Sun Mar 20 18:55:16 CET 2005

Matteo Dell'Amico wrote:
> Kay Schluehr wrote:
> > Why do You set
> >
> > d.defaultValue(0)
> > d.defaultValue(function=list)
> >
> > but not
> >
> > d.defaultValue(0)
> > d.defaultValue([])
> >
> > ?
> I think that's because you have to instantiate a different object for

> each different key. Otherwise, you would instantiate just one list as
> default value for *all* default values.

Or the default value will be copied, which is not very hard either or
type(self._default)() will be called. This is all equivalent and it
does not matter ( except for performance reasons ) which way to go as
long only one is selected.


> By the way, to really work, I think that Duncan's proposal should
> new objects when you try to access them, and to me it seems a bit
> counterintuitive.

If the dict has a fixed semantics by applying defaultValue() and it
returns defaults instead of exceptions whenever a key is missing i.e.
behavioural invariance the client of the dict has nothing to worry
about, hasn't he?

> > And why not dict(type=int), dict(type=list) instead where default
> > values are instantiated during object creation? A consistent
> > handling of all types should be envisioned not some ad hoc
> > that go deprecated two Python releases later.
> I don't really understand you. What should 'type' return?
> A callable
> that returns a new default value? That's exactly what Duncan proposed

> with the "function" keyword argument.

I suspect the proposal really makes sense only if the dict-values are
of the same type. Filling it with strings, custom objects and other
stuff and receiving 0 or [] or '' if a key is missing would be a
surprise - at least for me. Instantiating dict the way I proposed
indicates type-guards! This is the reason why I want to delay this
issue and discuss it in a broader context. But I'm also undecided.
Guidos Python-3000 musings are in danger to become vaporware. "Now is
better then never"... Therefore +0.

Regards Kay

More information about the Python-list mailing list