On Sun, Oct 30, 2011 at 11:11 PM, Mike Meyer
Python, as a general rule, tries to be "safe" about things. If something isn't obviously correct, it tends to throw runtime errors to let you know that you need to be explicit about what you want. ...
The one glaring exception is in concurrent programs. ...
Object semantics don't need to change very much. The existing immutable types will work well in this environment exactly as is.
I think a state bit in the object header would be more than justified, if we could define immutability. Are strings immutable? Do they become immutable after the hash is cached and the string is marked Ready? Can a subtype of strings with mutable attributes (that are not involved in comparison?) still be considered immutable?
The protection mechanism is the change to the language. I propose a single new keyword, "locking", that acts similar to the "try" keyword. The syntax is:
'locking' value [',' value]*':' suite
... The list of values are the objects that can be mutated in this lock.
You could already simulate this with a context manager ... it won't give you all the benefits (though with a lint-style tool, it might), but it will showcase the costs. (In terms of code beauty, not performance.) Personally, I think those costs would be too high, given the current memory model, but I suppose that is at least partly an empirical question. If there isn't a way to generate this list automatically, it is the equivalent of manual memory management. -jJ