> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4