f



embedding python in python #3

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
0
mauriceling (222)
9/29/2004 9:23:28 AM
comp.lang.python 77058 articles. 6 followers. Post Follow

8 Replies
945 Views

Similar Articles

[PageSpeed] 56

Use exec.

On Wed, Sep 29, 2004 at 09:23:28AM +0000, Maurice LING wrote:
> 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 *")
0
indigo9502 (83)
9/29/2004 12:47:03 PM
Maurice LING <mauriceling@acm.org> wrote in message news:<415a7f0b$1@news.unimelb.edu.au>...
> 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 *")
0
9/29/2004 5:38:09 PM
Lonnie Princehouse wrote:
> Maurice LING <mauriceling@acm.org> wrote in message news:<415a7f0b$1@news.unimelb.edu.au>...
> 
>>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 *")

Thank you.
0
mauriceling (222)
9/29/2004 11:12:37 PM
Maurice LING wrote:

> Lonnie Princehouse wrote:
> 
>> Maurice LING <mauriceling@acm.org> wrote in message 
>> news:<415a7f0b$1@news.unimelb.edu.au>...
>>
>>> 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 *")
> 
> 
> 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
0
steve73 (4801)
9/30/2004 12:19:38 PM
Hi,

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

 >>> def b(s):
....     exec(s)
....     exec('print "x= " + str(x)')
....
 >>> b('x = 10')
x= 10
 >>>
 >>> print x
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
NameError: name 'x' is not defined
 >>>

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
0
mauriceling (222)
9/30/2004 11:09:16 PM
Maurice LING wrote:

> Hi,
>
> Sorry, I have another problem here. Given this snipplet,
>
> >>> def b(s):
> ...     exec(s)
> ...     exec('print "x= " + str(x)')
> ...
> >>> b('x = 10')
> x= 10
> >>>
> >>> print x
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> NameError: name 'x' is not defined
> >>>
>
> Clearly, all the objects that were declared using exec() in function b 
> went out of scope, is there anyway to prevent this from happening?


 >>> myglobals = {}
 >>> mylocals = {}
 >>> exec "b = 1 + 2" in myglobals, mylocals
 >>> mylocals
{'b': 3}
 >>> exec "c = b * 2" in myglobals, mylocals
 >>> mylocals
{'c': 6, 'b': 3}
 >>> >>>

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

0
jeff27 (344)
10/1/2004 12:17:06 AM
> 
>  >>> myglobals = {}
>  >>> mylocals = {}
>  >>> exec "b = 1 + 2" in myglobals, mylocals
>  >>> mylocals
> {'b': 3}
>  >>> exec "c = b * 2" in myglobals, mylocals
>  >>> mylocals
> {'c': 6, 'b': 3}
>  >>> >>>
> 
> 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
0
mauriceling (222)
10/1/2004 12:49:43 AM
Maurice LING wrote:

> 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 --

 >>> myglobals = {}
 >>> mylocals = {}
 >>> foo = 5
 >>> exec "bar = foo * 5"
 >>> bar
25
 >>> exec "bar = foo * 5" in myglobals, mylocals
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "<string>", line 1, in ?
NameError: name 'foo' is not defined
 >>> 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

0
jeff27 (344)
10/1/2004 1:13:00 AM
Reply: