Running external module and accessing the created objects
davea at davea.name
Tue Mar 12 03:16:17 CET 2013
On 03/11/2013 09:58 PM, Kene Meniru wrote:
> Dave Angel wrote:
>> On 03/11/2013 07:57 PM, Kene Meniru wrote:
>> 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.
> 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
> - 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
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
there's no special problem accessing its globals.
More information about the Python-list