Guido's on_missing() proposal is pretty good for what it is, but it is not a replacement for set_default(). The use cases for a derivable, definition or instantiation time framework is different than the call-site based decision being made with setdefault(). The difference is that in the former case, the class designer or instantiator gets to decide what the default is, and in the latter (i.e. current) case, the user gets to decide. Going back to first principles, the two biggest problems with today's setdefault() is 1) the default object gets instantiated whether you need it or not, and 2) the idiom is not very readable. To directly address these two problems, I propose a new method called getdefault() with the following signature: def getdefault(self, key, factory) This yields the following idiom: d.getdefault('foo', list).append('bar') Clearly this completely addresses problem #1. The implementation is simple and obvious, and there's no default object instantiated unless the key is missing. I think #2 is addressed nicely too because "getdefault()" shifts the focus on what the method returns rather than the effect of the method on the target dict. Perhaps that's enough to make the chained operation on the returned value feel more natural. "getdefault()" also looks more like "get()" so maybe that helps it be less jarring. This approach also seems to address Raymond's objections because getdefault() isn't "special" the way on_missing() would be. Anyway, I don't think it's an either/or choice with Guido's subclass. Instead I think they are different use cases. I would add getdefault() to the standard dict API, remove (eventually) setdefault(), and add Guido's subclass in a separate module. But I /wouldn't/ clutter the built-in dict's API with on_missing(). -Barry P.S. _missing = object() def getdefault(self, key, factory): value = self.get(key, _missing) if value is _missing: value = self[key] = factory() return value