Guido van Rossum wrote:
Yes, this is a good thing. Easy to do on lists and dicts. Questions:
- How to spell it? x.freeze()? x.readonly()?
Ping:
I'm not so sure. There seem to be many issues here. More questions:
What's the difference between a frozen list and a tuple?
A frozen list can be unfrozen (maybe)?
Is a frozen list hashable?
Yes -- that's what started this thread (using dicts as dict keys, actually).
- Should this reversible? I.e. should there be an x.unfreeze()?
What if two threads lock and then unlock the same structure?
That's up to the threads -- it's no different that other concurrent access.
- Should we support something like this for instances too? Sometimes it might be cool to be able to freeze changing attribute values...
If you do this, i bet people will immediately want to freeze individual attributes. Some might be confused by
a.x = [1, 2, 3] lock(a.x) # intend to lock the attribute, not the list a.x = 3 # hey, why is this allowed?
That's a matter of API. I wouldn't make this a built-in, but rather a method on freezable objects (please don't call it lock()!).
What does locking an extension object do?
What does adding 1 to an extension object do?
What happens when you lock an object that implements list or dict semantics? Do we care that locking a UserList accomplishes nothing?
Who says it doesn't?
Should unfreeze/unlock() be disallowed in restricted mode?
I don't see why not. --Guido van Rossum (home page: http://www.python.org/~guido/)