On Thu, Jul 6, 2017 at 2:24 AM, eryk sun <eryk...@gmail.com> wrote: >> But what could it do? Most likely, it's going to end up mutating a >> dict (the core type), so unless the __setitem__ is itself maintaining >> complex state that needs a lock, all you've done is move the problem >> around, and the same solutions work. > > That was my point. A namespace mapping could override __setitem__ and > __getitem__ to implement a name as something like a computed property > that's based on multiple values. Then if __setitem__ gets interrupted > in the middle of updating this set of values, another thread that gets > the computed 'property' will see a bad state. The GIL doesn't help. It > would need locking to make accessing the 'property' work as an atomic > operation, just like the case with regular properties. Again, I have > never seen anything like this in practice.
Sure it could. And if it does, it's *it's* responsibility to use locks - not the caller's. From the caller's point of view, it's still a single operation, and should remain so. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
