[Python-Dev] defaultdict proposal round three

[Tim Peters]

[Guido]
> ...
> What's the practical use case for not wanting __contains__() to
> function?

I don't know.  I have practical use cases for wanting __contains__()
to function, but there's been no call for those.  For an example,
think of any real use ;-)

For example, I often use dicts to represent multisets, where a key
maps to a strictly positive count of the number of times that key
appears in the multiset.  A default of 0 is the right thing to return
for a key not in the multiset, so that M[k] += 1 works to add another
k to multiset M regardless of whether k was already present.

I sure hope I can implement multiset intersection as, e.g.,

def minter(a, b):
    if len(b) < len(a): # make `a` the smaller, and iterate over it
        a, b = b, a
    result = defaultdict defaulting to 0, however that's spelled
    for k in a:
        if k in b:
            result[k] = min(a[k], b[k])
    return result

Replacing the loop nest with:

    for k in a:
        result[k] = min(a[k], b[k])

would be semantically correct so far as it goes, but pragmatically
wrong:  I maintain my "strictly positive count" invariant because
consuming RAM to hold elements "that aren't there" can be a pragmatic
disaster.  (When `k` is in `a` but not in `b`, I don't want `k` to be
stored in `result`)

I have other examples, but they come so easily it's better to leave
that an exercise for the reader.