[Python-Dev] defaultdict proposal round three (original) (raw)

Crutcher Dunnavant crutcher at gmail.com
Mon Feb 20 21:37:30 CET 2006

I'm thinking something mutch closer to this (note default_factory gets the key):

def on_missing(self, key): if self.default_factory is not None: value = self.default_factory(key) if self.on_missing_define_key: self[key] = value return value raise KeyError(key)

On 2/20/06, Crutcher Dunnavant <crutcher at gmail.com> wrote:

Sorry to chime in so late, but why are we setting a value when the key isn't defined?

It seems there are many situations where you want: a) default values, and b) the ability to determine if a value was defined. There are many times that I want d[key] to give me a value even when it isn't defined, but that doesn't always mean I want to save that value in the dict. Sometimes I do, sometimes I don't. We should have some means of describing this in any defaultdict implementation On 2/20/06, Guido van Rossum <guido at python.org> wrote: > I'm withdrawing the last proposal. I'm not convinced by the argument > that contains should always return True (perhaps it should also > insert the value?), nor by the complaint that a holy invariant would > be violated (so what?). > > But the amount of discussion and the number of different viewpoints > present makes it clear that the feature as I last proposed would be > forever divisive. > > I see two alternatives. These will cause a different kind of > philosophical discussion; so be it. I'll describe them relative to the > last proposal; for those who wisely skipped the last thread, here's a > link to the proposal: > http://mail.python.org/pipermail/python-dev/2006-February/061261.html. > > Alternative A: add a new method to the dict type with the semantics of > getattr from the last proposal, using defaultfactory if not None > (except onmissing 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). > > Parting shots: > > - Even if the defaultfactory were passed to the constructor, it still > ought to be a writable attribute so it can be introspected and > modified. A defaultdict that can't change its default factory after > its creation is less useful. > > - It would be unwise to have a default value that would be called if > it was callable: what if I wanted the default to be a class instance > that happens to have a call method for unrelated reasons? > Callability is an elusive propperty; APIs should not attempt to > dynamically decide whether an argument is callable or not. > > - A third alternative would be to have a new method that takes an > explicit defaut factory argument. This differs from setdefault() only > in the type of the second argument. I'm not keen on this; the original > use case came from an example where the readability of > > d.setdefault(key, []).append(value) > > was questioned, and I'm not sure that > > d.something(key, list).append(value) > > is any more readable. IOW I like (and I believe few have questioned) > associating the default factory with the dict object instead of with > the call site. > > Let the third round of the games begin! > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) _> ________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com >

-- Crutcher Dunnavant <crutcher at gmail.com> littlelanguages.com monket.samedi-studios.com

-- Crutcher Dunnavant <crutcher at gmail.com> littlelanguages.com monket.samedi-studios.com

More information about the Python-Dev mailing list