The future of Python immutability

[Ulrich Eckhardt]

Nigel Rantor wrote:
> John Nagle wrote:
>>     Immutability is interesting for threaded programs, because
>> immutable objects can be shared without risk.  Consider a programming
>> model where objects shared between threads must be either immutable or
>> "synchronized" in the sense that Java uses the term.
> 
> Yes, this is one of the reasons I am currently learning Haskell, I am
> not yet anywhwere near proficient but the reason I am looking into FP is
> because of some of the claims of the FP community, particularly Erlang,
> regarding the benefits of pure FP with respect to multi-threading.

Actually, I wouldn't say that FP itself changes anything there. However, FP
usually (correct me if I'm wrong) implies immutability of objects, i.e. no
variable assignment.


>  > Such programs are free of most race conditions, without much
>  > programmer effort to make them so.
> 
> I disagree. They are not free of most race conditions, and it still
> takes a lot of effort. Where did you get this idea from? Have you been
> reading some Java primer that attempts to make it sound easy?
[...]
>>     With this mechanism, multi-thread programs with shared data
>> structures can be written with little or no explicit locking by
>> the programmer.  If the restrictions are made a bit stricter,
>> strict enough that threads cannot share mutable unsynchronized data,
>> removal of the "global interpreter lock" is potentially possible.
>> This is a route to improved performance on modern multi-core CPUs.
> 
> Right, this is where I would love to have had more experience with
> Haksell.
> 
> Yes, as soon as you get to a situation where no thread can access shared
> state that is mutable your problems go away, you're also getting no work
> done becasue the threads, whilst they may be performing lots of
> interesting calculations have no way of allowing the rest of the
> program, or operating system, know about it.

I think it is the combination of immutable objects and message passing
(which he omitted mentioning) that is the point. I initially encountered
this principle in Erlang, but it also applies in other languages. For
example in C++, you can create MT-program using std::auto_ptr<T> for
mutable, exclusively owned objects and boost::shared_pointer<T const> for
shared, immutable objects.


> So, in response to your point of trying to get an immutable API so that
> Python can easily have multi-threaded programs that do not present race
> conditions I would say the following:
> 
> That is not the challenge, that's the easy part. The challenge is
> getting useful information out of a system that has only been fed
> immutable objects.

You're overly pessimistic. Immutable objects are a tool, not the holy grail.
Having them available can help you solve some problems, not all of them.
You obviously still need mutable data, but if you can restrict access to
them to just one thread, there is no need for synchronisation for them.
Lastly, for the message passing, you also need shared, mutable structures
(queues), so you can't live completely without conventional locking.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932