[Python-Dev] defaultdict proposal round three
Tim Peters
tim.peters at gmail.com
Tue Feb 21 05:44:20 CET 2006
[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.
More information about the Python-Dev
mailing list