Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #31131

Re: __builtins__ thread-safe / __builtins__ as function?

Date 2012-10-11 16:28 -0400
From Dave Angel <d@davea.name>
Subject Re: __builtins__ thread-safe / __builtins__ as function?
References <CAAj3U_Ce+F6u+mhUy+_3uNXp4ck2QXtUw+7VG4wo9H88hJs0pQ@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.2064.1349987335.27098.python-list@python.org> (permalink)

Show all headers | View raw


On 10/11/2012 10:16 AM, Juergen Bartholomae wrote:
> 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__.

And that's just the first problem.  Maybe you can just let your new
library revert to the old one unless the calling module specifically
activates the new features.

That way existing modules will continue to work the old way, and if they
want new features, they'll need to follow new constraints.  One of these
is no globals, including nothing added to __builtins__   But remember
that their own globals are just as problematic.


-- 

DaveA

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: __builtins__ thread-safe / __builtins__ as function? Dave Angel <d@davea.name> - 2012-10-11 16:28 -0400

csiph-web