The future of Python immutability

[Hendrik van Rooyen]

On Thursday 03 September 2009 21:07:21 Nigel Rantor wrote:

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

Is it really that difficult?  (completely speculative):

class MyAnswer(object):
    def __init__(self)
        self.finished = False
        self.Answer = None
        self.collected = False

Then when you start a thread, you give it an instance:

ans = MyAnswer()
list_of_answers.append(c)

worker_thread = thread.start_new_thread(worker, (ans, immutable_stuff ))

def worker(ans):
    ans.Answer = do_some_stuff()
    ans.finished = True

Then to see if everybody is finished:

runbool = True
While runbool:
    finished = False
    runbool = False
    for answer in list_of_answers:
        if answer.finished and not answer.collected:
            do_something(answer.Answer)
            answer.collected = True
        else:
            runbool = True

This scheme gives only one thread the license to make a change to the answer 
instance, so how can it go wrong?

You can also extend it for long running threads by playing ping pong with the 
two booleans -  the collector sets the collected boolean and clears the 
finished, and the worker must clear the collected boolean before starting a 
new cycle. ( the worker waits for not finished, then clears collected)

I do similar stuff in assembler and I have no problems - Am I missing 
something subtle?

Of course - working with immutable objects only is a bit like working with 
read only memory, or worse, write only memory  - not easy.

- Hendrik