The future of Python immutability
steven at REMOVE.THIS.cybersource.com.au
Tue Sep 8 10:21:18 CEST 2009
On Tue, 08 Sep 2009 09:38:51 +0200, Hendrik van Rooyen wrote:
> On Monday 07 September 2009 20:26:02 John Nagle wrote:
>> 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
>> 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
> I think that trying to make the language instead of the programmer
> responsible for this is a ball-buster. It is unlikely to be either easy
> or cheap. I would rather have the programmer responsible for the mental
> model, and give her the tools to do the job with.
That was the situation 20 years ago with memory management. I'm sure
people back then thought that the Right Solution was to give the
programmer tools to get the job done, and hope they can avoid
dereferencing nil pointers and memory leaks and all the other cruft of
hand-managing memory. Today, we have garbage collectors and high-level
languages like Ruby, Python, Haskell etc that manage that for you, and
even heavyweight garbage collectors are practical for the majority of
> In any case - if you do not actually like juggling with knives, then you
> should not be mucking around with concurrency, and by making the
> language safe, you are taking the fun out.
If by "fun" you mean "screaming horrors", I agree.
More information about the Python-list