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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 default_factory if not None > > (except on_missing 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 default_factory 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@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com > > > > > -- > Crutcher Dunnavant <[EMAIL PROTECTED]> > littlelanguages.com > monket.samedi-studios.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com