> > - 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/)
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