On Wed, Jul 5, 2017 at 5:06 PM, Chris Angelico <ros...@gmail.com> wrote: > 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.
I feel it's necessary to emphasize that there's nothing inherent in the CPython bytecode operations for storing and loading a name that guarantees atomicity. The namespace has to provide the guarantee that backs up a statement like "[y]ou can be confident that a single assignment will happen atomically". -- https://mail.python.org/mailman/listinfo/python-list
