__builtins__ thread-safe / __builtins__ as function?

Juergen Bartholomae bartholomae.juergen at googlemail.com
Thu Oct 11 10:16:18 EDT 2012


Hello.
I have quite a peculiar problem.

A little overview of our situation:
Our program enables our users to write their own python code (which they
use extensively).
Unfortunately, (due to us actually encouraging this in an earlier release
(!stupid!)) this meant that, in several cases, there are modules which use
__builtins__ as a kind of global dictionary, where various variables are
inserted, changed and read.

Now, currently we are updating our program from a single-threaded to a
multithreaded architecture.
-> Of course, this means that the same module can now run in several
threads at the same time, and, since __builtins__ is pretty much global in
the system, they all share the same __builtins__.

Unfortunately, the obvious solution (use something else instead of abusing
__builtins__) won't do, because, like I said, there are various existing
modules out there that we cannot control and which must continue to run as
expected.

One possible solution  is to somehow redirect every __builtins__ to a
function that returns a different __builtins__ dictionary for each thread
(such a function already exists).

MY QUESTION:
How can I redirect __builtins__ to a built-in function?
My first idea was using __getattr__, but this won't work for most modules,
because __getattr__ only works with classes, and the customer .py-files
might not have any.
This means the customer modules are simply objects of the class <modules>,
which is of course an unchangeable metaclass. (so, no way to add any
methods here)
I could do it if there was any way to load .py-files as any other class
than <modules>, maybe as a subclass, but I do not know how this could be
done.

So, I am really at a loss here.
Any help would be greatly appreciated.

Regards,
Juergen Bartholomae
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121011/2a485f42/attachment.html>


More information about the Python-list mailing list