Help understanding the decisions *behind* python? - immutable objects

[John Nagle]

Steven D'Aprano wrote:
> On Sun, 26 Jul 2009 11:24:48 -0700, John Nagle wrote:
> 
>>      An interesting issue is Python objects, which are always mutable.
>> A "dict" of Python objects is allowed, but doesn't consider the contents
>> of the objects, just their identity (address). Only built-in types are
>> immutable; one cannot create a class of immutable objects.
> 
> Yes you can, for some definition of "can":
> 
> http://northernplanets.blogspot.com/2007/01/immutable-instances-in-python.html
> 
> 
> Admittedly pure Python objects are only "cooperatively immutable". 

    Right.  I've been thinking about this as a way of improving
concurrency handling.  The general idea is that objects shared
across threads would have to be either be immutable or synchronized.
Regular objects would be limited to a single thread.  It's a path
to multithread programs without a global lock.  Needs more work
to become a serious proposal.  (It may not be worth the trouble;
a few years ago we were hearing about how 64-core CPUs were going
to become mainstream, but instead, the industry is going in the
direction of the same compute power for less money and with
less power consumption.)

				John Nagle