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
