[Python-Dev] defaultdict proposal round three (original) (raw)
Guido van Rossum guido at python.org
Mon Feb 20 22:28:46 CET 2006
- Previous message: [Python-Dev] defaultdict proposal round three
- Next message: [Python-Dev] defaultdict proposal round three
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2/20/06, Ian Bicking <ianb at colorstudy.com> wrote:
Also, is defaultfactory=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/)
- Previous message: [Python-Dev] defaultdict proposal round three
- Next message: [Python-Dev] defaultdict proposal round three
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]