The future of Python immutability

Paul Rubin http
Mon Sep 7 21:56:41 CEST 2009


John Nagle <nagle at animats.com> writes:
>     Right.  Tracking mutablity and ownership all the way down without
> making the language either restrictive or slow is tough.
> 
>     In multi-thread programs, though, somebody has to be clear on who owns
> what.  I'm trying to figure out a way for the language, rather than the
> programmer, to do that job.  It's a major source of trouble in threaded
> programs.

Python's threading system is modelled after Java's, which basically
uses explicit locks under programmer control.  That has its hazards
but does manage to multiprocess effectively.  CPython's
multiprocessing is limited by the notorious GIL, but that's an
implementation artifact.

Having the language automatically manage ownership of mutable objects
without a fancy type system sounds self-contradictory.  Erlang (which
is typeless like Python) does it by not allowing mutation at all.
Haskell uses a type-based scheme around software transactional memory
(STM) primitives:

  http://book.realworldhaskell.org/read/software-transactional-memory.html

The Microsoft Research "Singularity" OS may also be of interest.



More information about the Python-list mailing list