The future of Python immutability

[John Nagle]

     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.  Such programs
are free of most race conditions, without much programmer effort to
make them so.

     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.

     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.

					John Nagle