Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Sat, 09 Mar 2013 07:02:28 -0500
From: Dave Angel <davea@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Running external module and accessing the created objects
References: <mailman.3110.1362798411.2939.python-list@python.org> <513aecd3$0$6512$c3e8da3$5496439d@news.astraweb.com> <khf52d$o79$1@ger.gmane.org>
In-Reply-To: <khf52d$o79$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3125.1362830573.2939.python-list@python.org>
Lines: 62
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:40944

On 03/09/2013 06:05 AM, Kene Meniru wrote:
>
>   (lots of stuff that was more confusing to me than helpful)

You use the words launch, encountered, execute, and others in ways that 
do not make sense to me, or are at least ambiguous.

You have an explicitly named user.py, which apparently is *not* 
generally named that.

I could give you lots of random facts and suggestions, and one of the 
might hit home.  For example the __import__() function can import a 
module that you don't know the name of ahead of time.  It's not often 
the right answer, though, so I hesitate to suggest it.

For another example, if you import a module by two different names, or 
if you import the "module" that is your starting script, then you can 
end up with two instances of such a module, with all sorts of negative 
implications about global data or class attributes stored in that 
module, or even more subtle problems.

For a final example, having a circular import tree can cause problems if 
any of those imports have any global code (like class initialization, 
defining constants, etc.).  It's generally much better to define a 
strict hierarchy of who imports whom.

But I think instead that it'd be better for you to make a clearer 
statement about how your code is structured.

I'm guessing that all of this is intended to be in one executable -- no 
child processes, etc.  So don't say launch, say import, or 
function-call, or whatever you are really doing.

I'm guessing that you're running this on Python 3.3 under Linux.

I'm guessing that "user.py" is one possible name that a particular user 
calls his script.  And that script is what he runs on the Python 
commandline.

     python user.py

And that script calls functions in app.py, doc.py, and/or appwin.py. 
And that currently, you're trying to import user.py from one of your own 
modules, for purposes of either callback functions or global data 
access.  That's a mistake.  When you import your *script* (using 
__import__() as suggested above) you get a new copy of the script, and 
new copies of all its global data.

I can't even guess how you're intending to mix the commandline stuff of 
app.py with gui stuff in one or more appwin.py variants.  You'll have to 
be explicit, if it even matters yet.

I suggest that rather than responding to these points, you restate your 
problem, in one place, with coherent detail that eliminates these 
guesses and replaces them with reality.  Start with the environment this 
is running in, and the commandline typically used to launch the code, 
and the interdepencies of the various modules.



-- 
DaveA