The future of "frozen" types as the number of CPU cores increases

[John Nagle]

Terry Reedy wrote:
> On 2/16/2010 3:15 PM, John Nagle wrote:
>> In the beginning, Python had some types which were "frozen",
>  > and some which weren't.
> 
> In the beginning, there was only one 'frozen' general purpose collection 
> type, the tuple. And Guido resisted the suggestion that lists and tuple 
> were mutable and frozen versions of each other.
> 
> However, things have changed, and lists and tuple *are* effectively 
> mutable and hashable versions of each other, and we have the three other 
> pairs you mentioned. The idea of freeze() may have been floated (and 
> punctured) during Py3 discussions, but I think it a fairly good one.

    Yes, we're now at the point where all the built-in mutable types
have "frozen" versions.  But we don't have that for objects.  It's
generally considered a good thing in language design to offer,
for user defined types, most of the functionality of built-in ones.

    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.

					John Nagle