The future of Python immutability

[Nigel Rantor]

John Nagle wrote:
>     Python's concept of immutability is useful, but it could be more
> general.
> 
>     In the beginning, strings, tuples, and numbers were immutable, and
> everything else was mutable.  That was simple enough.  But over time,
> Python has acquired more immutable types - immutable sets and immutable
> byte arrays.  Each of these is a special case.
> 
>     Python doesn't have immutable objects as a general concept, but
> it may be headed in that direction.  There was some fooling around
> with an "immmutability API" associated with NumPy back in 2007, but
> that was removed.  As more immutable types are added, a more general
> approach may be useful.
> 
>     Suppose, for discussion purposes, we had general "immutable objects".
> Objects inherited from "immutableobject" instead of "object" would be
> unchangeable once "__init__" had returned.  Where does this take us?
> 
>     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.

It's a shame this post came right now since I'm not really up-to-speed 
enough with Haskell to comment on it with repsect to multi-threading.

<context>
I program Perl, Java and C++ for my day job, I've spent a lot of time 
making multithreaded programs work correctly and have even experienced 
the POE on a large project. So my comments below are based on experience 
of these languages.
</context>

 > 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?

>     Java "synchronized" turned out to be a headache partly because 
> trying to
> figure out how to lock all the "little stuff" being passed around
> a headache.  But Java doesn't have immutable objects.  Python does,
> and that can be exploited to make thread-based programming cleaner.

This is nothing to do with Java, any multithreaded language that has 
mutable shared state has exactly the same problems. Can we talk about 
threading rather than Java please? Additionally Java provides a lot more 
than monitors (synchronized) for controlling multiple threads.

Java does have immutable objects. Strings in Java are immutable for 
example. As are the object-based numeric types, Bytes, Characters etc.

There are lots and lots of immutable types in Java and you can make your 
own by creating a class with no mutator methods and declaring it "final".

>     The general idea is that synchronized objects would have built in
> locks which would lock at entry to any function of the object and
> unlock at exit.  The lock would also unlock at explicit waits.  A
> "Queue" object would be a good example of a synchronized object.
> 
>     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.

You can, today, in any language that provides threads, make any number 
of threaded programs that do not contain any race conditions, it's just 
that most of them are terribly dull and uninteresting.

I'd love for someone from the Haskell/Erlang/<other> pure FP community 
provide some canonical example of how this is acheived in pure FP. I'll 
get there soon but I'm not going to skip ahead in my reading, I'm still 
trying to learn the basics.

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.

Regards,

   Nigel