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
--
http://mail.python.org/mailman/listinfo/python-list
