Embedding and threads ?

[Bo Lorentsen]

On Thu, 2002-05-30 at 16:29, Martin v. Löwis wrote:

> No. The code object has a link to the builtins, and the sys module
> (and thus sys.modules) is a singleton, as well. So if the code performs
> 
> import string
> string.secret_channel = "data"
> 
> then this assignment will survive PyEval_EvalCode invocations. See
> Include/pystate.h for part of the state that is passed implicitly into
> PyEval_EvalCode.
Is it a dumb question to ask, if I asked why the two dict's are there as
parameters in the first place ? Do they overwrite the global ones ?

> Just assume that the interpreter is a singleton; having multiple
> interpreters might not work.
Does that mean --- "Python supports threads, but hey don't use them, as
it may not work" ? :-)

I can see that normally Python has a single ThreadState (and its related
Interpreter) that works as a singleton, but is it not possible to "swap"
these after getting the GIL, or am I totally off track here ?

> > What do you mean by a "rexec sandbox" ?
> 
> http://www.python.org/doc/lib/module-rexec.html
Yes !!! This is what I need ! But this is designed to be used inside
Python, but how about using something like this while embedding Python ?

> You need to edit pyconfig.h to not set HAVE_DYNAMIC_LOADING, then recompile 
But, how about making Python point to an invalid "site" path, or
something like it ? Or maybe I just need to look more into the rexec
module, as it look wery promissing.

> If you disable dynamic loading, and provide an appropriate config.c,
> then you get a limitation to math, re, and others for free. Preventing
> code from doing open() is not so trivial; you need to provide a custom
> __builtins__ module - you could do that by editing the Python
> interpreter code, by deleting things from __builtins__ at run-time, or
> by using rexec.
I think the rexec module sounds like the propper way to go. I also like
to keep using a standart version of Python, as special versions of a
major product often mess things up as the main product evolves.

> Depends on what you mean by "disable". If you want that writing to
> stdout has no effect: that is certainly possible. Just put in a
> file-like object whose .write method is a no-op.
Ok, thanks I'll se what I can do about it.

> print will always use sys.stdout, so that will be a no-op as well (the
> arguments to the print will still be evaluated).
Hmm, it would be nice to be able to redirect stdout. So, I will see if I
can manage to do that, and then no-op both stderr and stdin objects.

> The Global Interpreter Lock.
Ahh, thanks :-)

> This controls the start symbol of the parsing. It is eval_input,
> file_input, or single_input, and relates to the non-terminals in
> Grammar/Grammar with the same names. If that is not clear, you need to
> understand the notion of a start symbol in a grammar first.
I'm not sure I fully understand, but I get the general picture, thank.

Again, thanks for your answers, I am already making my first embeded
code tests, and it is wery easy to manage, and somewhat nice to look at
:-)

/BL