[Python-Dev] defaultdict proposal round three

Guido van Rossum guido at python.org
Mon Feb 20 22:28:46 CET 2006

On 2/20/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Also, is default_factory=list threadsafe in the same way .setdefault is?
>   That is, you can safely do this from multiple threads:
>    d.setdefault(key, []).append(value)
> I believe this is safe with very few caveats -- setdefault itself is
> atomic (or else I'm writing some bad code ;).

Only if the key is a string and all values in the dict are also
strings (or other builtins). And I don't think that Jython or
IronPython promise anything here.

Here's a sketch of a situation that isn't thread-safe:

class C:
  def __eq__(self, other):
    return False
  def __hash__(self):
    return hash("abc")

d = {C(): 42}
print d["abc"]

Because "abc" and C() have the same hash value, the lookup will
compare "abc" to C() which will invoke C.__eq__().

Why are you so keen on using a dictionary to share data between
threads that  may both modify it? IMO this is asking for trouble --
the advice about sharing data between threads is always to use the
Queue module.

> Note that multidict -- among other possible concrete collection patterns
> (like Bag, OrderedDict, or others) -- can be readily implemented with
> threading guarantees.

I don't believe that this is as easy as you think.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list