Running external module and accessing the created objects

Rick Johnson rantingrickjohnson at
Sat Mar 9 17:51:35 CET 2013

On Saturday, March 9, 2013 9:34:53 AM UTC-6, Kene Meniru wrote:
> OK. Sorry to have caused all the confusion. Let me try
> this again.

Sounds to me like you should solve this problem in two manners:

 Interactive Input

Create an interactive environment where the user can enter commands directly into the namespace using your API in real time, then when he is ready to see the result of those commands, he can call "display command" or push a "display button" and the App will run the appropriate outside programs to show the visualization. 

 Scripts loaded at runtime

If you prefer the user to write "scripts", and then have your App read these scripts (and create visualizations from the commands within the scripts) then the only difference between step 1 and step 2 is *when* the commands are interpreted. In this case your app will *load* the scripts AFTER they are completely written (this could be done automatically by the app at runtime IF the path to these scripts is known, or could be accomplished by the user picking files in a dialog (Menu->RunScript).

I think you are trying to create step 1 without the interactive environment. This is your mistake. Having users work with "raw files" and then *somehow* watching a "raw file" for certain "display commands" (in real time) is folly. 

Heck, when you edit a file in a text editor you are only seeing a representation of the file from the last time it was saved, and your app could never know when the "file data" and the "file view" where synchronized; without an asinine amount of foolish programming of course.

If this is not what you want, then i suggest you create a simple representation of your code (or link to the actual code).

More information about the Python-list mailing list