Georg Brandl wrote:
I think I like Jeff's approach more (defaultvalues are just special cases of default factories); there aren't many "hoops" required. Apart from that, the names just get longer ;)
Yes Jeff's approach does simplify the implementation and more-or-less eliminates my complexity objection
But why do you write:
def __getitem__(self, key):
try:
return super(defaultdict, self).__getitem__(key)
except KeyError, err:
try:
return self.setdefault(key,
self._default[0](*self._default[1],
**self._default[2]))
except KeyError:
raise errrather than:
def __getitem__(self, key):
return self.setdefault(key,
self._default[0](*self._default[1],
**self._default[2]))(which could catch AttributeError in the case of _default not set) I'm sure there's a reason, but I can't see it.
...
2. I would really prefer to have the default value specified in the constructor
Too much specialcased for my liking.
It does set up some gotchas I concede ;-)
...
Alternatively, you could provide factory functions to construct the defaultdict. Someone (Michele?) recently posted an implementation of this
Yes, I think this could be reasonable.
...though this would more naturally complement a fixed-default dictionary IMO
Your design permits - even encourages (by providing convenient setters) the default to change over the lifetime of the dictionary. I'm not sure whether that's good or bad, but it's a feature worth discussing.
3. Can you work in the tally and listappend methods that started this whole thread off?
They aren't necessary any longer.
Use defaultdict.setdefaultvalue(0) instead of the tally approach and defaultdict.setdefaultfactory(list) instead of listappend.
Oops, I see what you mean... then use += or append as required. I still prefer the clarity of tally for its specific use-case, but it does suffer from lack of generality.
Michael
-- http://mail.python.org/mailman/listinfo/python-list
