The future of "frozen" types as the number of CPU cores increases
Alf P. Steinbach
alfps at start.no
Wed Feb 17 07:17:25 CET 2010
* Paul Rubin:
> John Nagle <nagle at animats.com> writes:
>>> However, things have changed, and lists and tuple *are* effectively
>>> mutable and hashable versions of each other...
>> It's the concurrency aspect of this that interests me, though.
>> A language with immutable objects can potentially handle concurrency
>> more safely than one where everything is potentially mutable.
>> The language knows what can't change, which simplifies locking.
> I wonder how well that applies to tuples containing mutable objects,
> e.g. t = ([1,2], [3,4])
One would need a collection type that's immutable "all the way".
Current frozen types don't have that.
However, there's also the question of the immutability of what names refer to.
It seems to me that this means that the compiler can't really assume very much
without very deep analysis. And so, if it boils down to the programmer applying
assumptions about mutability/constantness, then types may not be The Answer.
More information about the Python-list