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

[Benjamin Kaplan]

On Sun, Jul 26, 2009 at 2:24 PM, John Nagle<nagle at animats.com> wrote:
> 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.


Python dictionaries are hash maps so they use hashes, not comparisons,
to store objects. By default the hash is equal to the object's
identity but all you need to do to change it is define your own
__hash__ method. If you were to make a C++ hash map, it wouldn't use
comparisons either.


>
>    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
> --
> http://mail.python.org/mailman/listinfo/python-list
>