Running external module and accessing the created objects

[Dave Angel]

Tried __import__ and it seems to execute the myapp.py just like execfile
however it only provides access to objects defined in the module myapp.py
only. Like I mentioned, my program has multiple packages and the objects
myappwin needs access to are stored in an object in another module called
doc.py.

- myapp.py provides the functions used to describe 3D objects
- app.py is imported into myapp.py and is called by the functions after they
create the 3D objects.
- app.py uses another module called doc.py which app.py imports to save the
objects in a class with a dictionary.
- myappwin needs to access the dictionary in the class inside the doc
module.

If you need access to modules in your own framework, then import them
yourself. You don't need any strange indirection through the myapp.py
module. It's because you said that name was arbitrary and would change
from run to run that we had to special case it.

Same as you do with sys module in the standard library. It may get
imported from dozens of places, and as long as they all import it by simple
import sys

there's no special problem accessing its globals.

 

[Michael Torrie]

I hope you're just kidding. execfile() and exec() are two of the most
dangerous mechanisms around. import or __import__() would be much
better, as long as your user hasn't already run myapp.py as his script.

It's not possible to setuid a python script, so I don't see how execfile
or exec is any more dangerous than the user creating a shell script that
rm -rf * things, and then running it.

Bash "exec's" scripts all the time that users create and provide. How
is this different and what issues did you have in mind, exactly?

 

[Rick Johnson]

------------------------------------------
# contents of myapp.py
import math

class MyApp(object):
def __init__(self):
super(MyApp, self).__init__()
self.name = "MyAppName"


def testFunction():
boke = "Smilling"
print math.sin(1), boke
-----------------------------------------
# contents of myappwin
def test():
dic = {}
execfile("myapp.py", dic)
testObj = dic["MyApp"]() # access MyApp class
dic["testFunction"]() # execute testFunction
print testObj.name # print string


test()
-----------------------------------------
# OUTPUT
$ python myappwin.py
0.841470984808 Smilling
MyAppName

Hmm. I don't understand why you think a simple old import won't work. Here is code (with names slightly adjusted for sanity).

============================================================
Contents of "mymodule.py"
============================================================

import math

class Foo(object):
def __init__(self):
super(Foo, self).__init__()
self.name = "MyAppName"

def foo():
boke = "Smilling"
print math.sin(1), boke

============================================================
Contents of "myscript.py"
============================================================

# This next import statement requires that a script named
# "myapp.py" exist on the Python search path. If you cannot
# bring the script into the search path, you can bring the
# search path to the script by editing "sys.path".
#
# import sys
# sys.path.append('foderContainingMyModule')
# del sys
#
# But i would suggest placing the module on search path.

from mymodule import Foo, foo

def test():
## dic = {}
## execfile("myapp.py", dic)
## testObj = dic["MyApp"]() # access MyApp class
instance = Foo()
## dic["testFunction"]() # execute testFunction
foo()
## print testObj.name # print string
print instance.name

if __name__ == '__main__':
test()

============================================================
Results of running "myscript"
============================================================

0.841470984808 Smilling
MyAppName

 

[Dave Angel]

It's not possible to setuid a python script, so I don't see how execfile
or exec is any more dangerous than the user creating a shell script that
rm -rf * things, and then running it.

Bash "exec's" scripts all the time that users create and provide. How
is this different and what issues did you have in mind, exactly?

Mainly that exec and execfile are a slippery slope for a new programmer.
Once as they get it in their minds that this is the way to do things,
they'll soon fall into using one of them on raw_input() data, on network
data, and on other untrusted sources.

 

[Kene Meniru]

The __import__() function is defined
http://docs.python.org/2/library/functions.html#__import__

Thanks. The name of the imported file will change with each user and for
each project so according to the this reference using this in my situation makes
sense.

appname = "myapp"
usermodule = __import__(appname, globals(), locals(), [], -1)

And now you can use usermodule as though you had imported it in the
usual way.

Thanks. This worked! I was using __import__ without the other arguments
before. I guess did not think it will work

As for my other caveat, I've said it before in this thread. Make sure
you don't ever load a module by more than one name, or you'll end up
with a mess. And that includes the original script, which is loaded by
the name '__main__'

You also should avoid any circular import, as it can be very tricky to
deal with them.

The two programs are separate, there is no fear of a circular import. Also,
I need only a function to get access to the objects in the other module so
the import is inside the function... no fear of ending up in a mess.

Thanks. I guess this makes more sense than execfile and it works.

 

[Kene Meniru]

It's not possible to setuid a python script, so I don't see how execfile
or exec is any more dangerous than the user creating a shell script that
rm -rf * things, and then running it.

Bash "exec's" scripts all the time that users create and provide. How
is this different and what issues did you have in mind, exactly?

This is close to my reasoning too, although I appreciate Dave's concern.