Kay Schluehr wrote:
I think that's because you have to instantiate a different object for each different key. Otherwise, you would instantiate just one list as a 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.
I don't like it very much... it seems too implicit to be pythonic. Also, it won't work with non-copyable objects, and type(42)() = 0, and getting 0 when the default is 42 looks very strange. I prefer the explicit "give me a callable" approach.
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?
For idioms like d[foo].append('blah') to work properly, you'd have to set the default value every time you access a variable. It can be really strange to fill up memory only by apparently accessing values.
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.
Having duck-typing, we can have things that have common interface but no common type. For instance, iterables. I can imagine a list of iterables of different types, and a default value of maybe [] or set([]).
-- Ciao, Matteo -- http://mail.python.org/mailman/listinfo/python-list
