- How to spell it? x.freeze()? x.readonly()?
I like "freeze", it'a a clear imperative where "readonly()" sounds like a test (e.g. "is this readonly()?")
Agreed.
- Should we support something like this for instances too? Sometimes it might be cool to be able to freeze changing attribute values...
Moshe Zadka sent me a hack that handles instances: [...]
OK, so no special support needed there.
- Should this reversible? I.e. should there be an x.unfreeze()?
I gave this some thought earlier today. There are advantages to either way. Making freeze a one-way operation would make it possible to use freezing to get certain kinds of security and integrity guarantees that you can't have if freezing is reversible.
Fortunately, there's a semantics that captures both. If we allow freeze to take an optional key argument, and require that an unfreeze call must supply the same key or fail, we get both worlds. We can even one-way-hash the keys so they don't have to be stored in the bytecode.
Want to lock a structure permanently? Pick a random long key. Freeze with it. Then throw that key away...
Way too cute. My suggestion freeze(0) freezes forever, freeze(1) can be unfrozen. --Guido van Rossum (home page: http://www.python.org/~guido/)