>> One possible solution  is to somehow redirect every __builtins__ to a<br>>> function that returns a different __builtins__ dictionary for each thread<br>>> (such a function already exists).<br><br>>How exactly does the code reference it? If they're simply referring to<br>
>the name __builtins__ at module level, you ought to be able to import<br>>the module, then assign some_module.__builtins__ to your thread-local<br>>object, then call code in it as normal.<br><br>>An interesting problem, and one where monkeypatching is, imho, justified.<br>
<br>>ChrisA<br><br><div>Hello, and thanks for your answer.</div><div>Unfortunately, replacing __builtins__ at import time won't do, because<br>
external modules (that is, .py) get imported only once when they are</div><div>accessed by the first thread, which includes (of course) setting up of</div><div>__dict__ and __builtins__. When a second thread later accesses this</div>

<div>module, it has the same variables in __builtins__ that were added by</div><div>the same module in first thread</div><div>And if the second thread then changes the values, I can see these<br>same changes in the first thread.</div>

<div>-> The problem is that __builtins__ are global, not thread-safe.</div><div> </div><div>The only solution I can see is therfor redirecting __builtins__ to a<br>function which returns a different dictionary for each thread, e.g.</div>

<div>by intercepting __builtins__-calls with __readattr__.</div><div>To do this, I would need my own class to define __readattr__ in</div><div>since (as far as I know) I can't define __readattr__ in a module,</div><div>

and I can't change metaclass <module> of course.</div><div> </div><div>I really don't know how to get around this problem...</div><br>