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

Crutcher Dunnavant crutcher at gmail.com
Mon Feb 20 21:34:44 CET 2006

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

More information about the Python-Dev mailing list