On Mon, Oct 31, 2011 at 3:58 PM, Bruce Leban firstname.lastname@example.org wrote:
On Sun, Oct 30, 2011 at 8:11 PM, Mike Meyer email@example.com wrote:
Any attempt to mutate an object that isn't currently locked will raise an exception. Possibly ValueError, possibly a new exception class just for this purpose. This includes rebinding attributes of objects that aren't locked.
Do you mean that at any time attempting to mutate an unlocked object throws an exception?
Yes, that's the idea. There are some exceptions, but you have to explicitly work around that restriction.
That would mean that all of my current code is broken.
Pretty much, yes. It's like adding garbage collection and removing alloc*/free. It's going to break a *lot* of code. That's why I said "not in 3. and possibly never in cPython."
Do you mean, that inside the control of 'locking', you can't mutate an unlocked object? That still breaks lots of code that is safe. You can't use itertools.cycle anymore until that's updated in a completely unnecessary way:
def cycle(iterable): # cycle('ABCD') --> A B C D A B C D A B C D ... saved =  for element in iterable: yield element saved.append(element) *# throws an exception when called on a locked iterable* while saved: for element in saved: yield element
According to what I wrote, yes, it does.Since the list being mutated is only visible inside the function, it doesn't need to be. It might be possible to figure out that this is the case at compile time and thus allow the code to run unmodified. But that's 1) hard, 2) will miss some cases, 3) seems like a corner case. This proposal would break enough code that not breaking this case doesn't seem to be worth the effort. That's a question that needs to be answered.
I think the semantics of this need to be tightened up.
That's why I brought it up. I'm trying to get more eyes on the issue.
Furthermore, merely *reading* an object that isn't locked can cause problems. This code is not thread-safe:
if element in dictionary: return dictionary[element]
so you have to decide how much safety you want and what cost we're willing to pay for this.
You're right - it's not thread safe. However, it also doesn't suffer from the problem I'm trying to deal with, where you mutate an object in a way that leaves things broken, but won't be detected at that point. If it breaks because someone mutates the object underneath it, it'll throw an exception at that point. I know you can construct cases where that isn't so. Maybe we need two types of locking - one that allows readers, and one that doesn't. I could live with that, as you'd still have to consider the issue where you mutate the object.