embedding python in python

[Maurice LING]

Hi,

anyone had any experiences in embedding python in python?

I've tried to do this but it doesn't work.

eval("from Tkinter import *")

Thanks
maurice

 

[Phil Frost]

Use exec.

 

[Lonnie Princehouse]

Hi,

anyone had any experiences in embedding python in python?

I've tried to do this but it doesn't work.

eval("from Tkinter import *")

Thanks
maurice

You need exec for statements:

exec("from Tkinter import *")

 

[Maurice LING]

You need exec for statements:

exec("from Tkinter import *")

Thank you.

 

[Steve Holden]

Thank you.

.... and note that exec is a statement introduced by a keyword, not a
function call, so

exec "from Tkinter import *"

is a less misleading way to write it.

regards
Steve

 

[Maurice LING]

Hi,

Sorry, I have another problem here. Given this snipplet,
.... exec(s)
.... exec('print "x= " + str(x)')
....Traceback (most recent call last):

Clearly, all the objects that were declared using exec() in function b
went out of scope, is there anyway to prevent this from happening?

What I really need is this, for example, in a class,

1. a function to initialize a set of objects
2. a function which carries commands to act on the object (unknown at
compile time)
3. a function to read the values of the set of objects

So, if the objects went out of scope after leaving (1), then I am rather
screwed when I'm in (2). Any remedies?

Thanks
Maurice

 

[Jeff Shannon]

Hi,

Sorry, I have another problem here. Given this snipplet,

... exec(s)
... exec('print "x= " + str(x)')
...
Traceback (most recent call last):


Clearly, all the objects that were declared using exec() in function b
went out of scope, is there anyway to prevent this from happening?

The exec statement can take an optional pair of dictionaries that it
uses as the global and local namespaces to execute the given code in.
This is *much* preferable to a bare exec for several reasons, one of
them being exactly your issue, and another being safety -- since you
must explicitly include any names that you want exec to use, it makes
exec rather less likely to unintentionally stomp all over your namespace
(or for malicious code to do certain types of harm).

Jeff Shannon
Technician/Programmer
Credit International

 

[Maurice LING]

The exec statement can take an optional pair of dictionaries that it
uses as the global and local namespaces to execute the given code in.
This is *much* preferable to a bare exec for several reasons, one of
them being exactly your issue, and another being safety -- since you
must explicitly include any names that you want exec to use, it makes
exec rather less likely to unintentionally stomp all over your namespace
(or for malicious code to do certain types of harm).

Jeff Shannon
Technician/Programmer
Credit International

Please pardon me for my dumbness but what exactly goes on in


exec "b = 1 + 2" in myglobals, mylocals

?

Thanks
Maurice

 

[Jeff Shannon]

Please pardon me for my dumbness but what exactly goes on in

exec "b = 1 + 2" in myglobals, mylocals

What's happening is that I've provided two dictionaries for exec to use
as a global namespace and a local namespace, respectively. In this
particular example, both namespaces are empty, but we're not looking up
any names in those namespaces, so that doesn't matter. We *are* binding
a name ('b') in the local namespace. That local namespace is the dict
I've named mylocals, so when exec is finished I can reference
mylocals['b'] and find the value that 'b' was bound to inside the exec
statement.

The next example is a bit more complex. I'm passing the same
dictionaries, but now the local namespace contains that reference to
'b'. The exec statement looks up that name, finds that it's bound to
the value 3, multiplies that value by 2, and binds the result to 'c',
again all in the local namespace (which is still the mylocals dict).
Now I've got *two* names bound in mylocals -- 'b' and 'c'.

Note that my initial dictionaries don't need to be empty. Just as was
demonstrated in the second example, if there are entries in those
dictionaries then the exec'd code can refer to them as if they were
normal (global or local) variable names. This also means that exec'd
code can't refer to any *other* global or local variables --
Traceback (most recent call last):
File "<interactive input>", line 1, in ?

>>> myglobals['foo'] = 10
>>> exec "bar = foo * 5" in myglobals, mylocals
>>> mylocals {'bar': 50}
>>>

When using a bare exec, the current local and global namespaces are
used, so exec finds 'foo' and binds 'bar'. But when I give exec two
empty dicts, the name 'foo' is undefined within the exec statement, even
though it exists in the interpreter's namespace. After creating 'foo'
within myglobals, though, exec can find it, and then binds 'bar' within
mylocals.

In short, you can carefully construct a global and local namespace for
your exec'd code, which contains only those variables that you *want*
that code to see. If that exec'd code binds any new variable names,
then those names will remain in those namespaces when exec is done, so
you can retrieve them later.

Jeff Shannon
Technician/Programmer
Credit International