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

[John Nagle]

Beni Cherniavsky wrote:
> On Jul 22, 9:36 am, Hendrik van Rooyen <hend... at microcorp.co.za>
> wrote:
>> On Tuesday 21 July 2009 15:49:59 Inky 788 wrote:
>>
>>> My guess is that it was probably for optimization reasons long ago.
>>> I've never heard a *good* reason why Python needs both.
>> The good reason is the immutability, which lets you use
>> a tuple as a dict key.  
>>
> On Jul 22, 9:36 am, Hendrik van Rooyen <hend... at microcorp.co.za>
> wrote:
>> On Tuesday 21 July 2009 15:49:59 Inky 788 wrote:
>>
>>> My guess is that it was probably for optimization reasons long ago.
>>> I've never heard a *good* reason why Python needs both.
>> The good reason is the immutability, which lets you use
>> a tuple as a dict key.
>>
> The *technical* reason is immutability for dict keys.
> Dict could allow mutable objects as keys by comparing *by value*,
> making a copy on insertion and hashing the current value on lookup.
> Prior art: the 2.3 sets module allows mutable Sets as elements in
> Sets, by making ImmutableSet copies on insertion, and hashing Sets as
> if they are temporarily immutable on lookup.
> 
> This inspired PEP 351 and ambitious proposals to expand the approach
> to all Python with a copy-on-write scheme.  But these ideas were
> rejected, and the 2.4 builtin sets only allow frozenset elements.
> Half the reason is technical: copy-on-write and harder than it sounds,
> and without it you pay a performance price.
> 
> But the deeper reason is style: immutable types are convenient!
> The allow a pure-functional style of code, which can be simpler.
> Of course, sometimes an imperative style is simpler.  Depends on the
> problem.

     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.
So things like "frozenset" had to be built into the language.
A tuple is really a frozen list.  Arguably, frozen objects
should have been a general concept.  Conceptually, they're
simple - once "__init__" has run, there can be no more changes
to fields of the object.

     Compare the C++ approach, where you can have a "map" of
any object that defines the "<" operator.  Python has
"__cmp__" for objects, but built-in dictionaries don't use it.
Of course, one could create a "map" class in Python that
uses "__cmp__", which would allow dictionary-type operations
on arbitrary objects.

     There are some interesting uses for immutable objects in
multithreaded programs.  They can be shared between threads
without locking.  If it weren't for the infamous Global
Interpreter Lock, which basically limits Python programs to using
one CPU at a time, Python would have to deal with locking
in a more advanced way.  A system where immutable objects
can be shared and passed between threads, and mutable objects
must be "synchronized" (in the Java sense) to be shared would
be useful.

				John Nagle