Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Guy Gascoigne-Piggford <ggp@tr...> - 2002-02-11 18:17:33
Well that's a good work around until I find a better way to do it, but that
means that all of my shipped scripts need to have import xxx reload xxx in
them, more to the point this is a hassle that I really didn't want to have
to expose to the user. I didn't realize that there was so mush shared state
between separate invocations of PythonInterpreter. Why create a new Object
if all you are getting is a reference to an existing shared environment?
Makes me wonder just how thread safe it is.
From: Kevin Butler [mailto:kbutler@...]
Sent: Monday, February 11, 2002 8:21 AM
To: Guy Gascoigne-Piggford
Subject: Re: [Jython-dev] import problem with changed modules
> I figured that I would be much more likely to get an answer to my
> problem if I explained it a bit more carefully J
Yes - I didn't have an answer for the previous version. :-)
> So, if I have two modules, mod_A and mod_B, and mod_A imports mod_B,
> if create a PythonInterpreter and exec mod_A, and then whilst the
> system is running edit mod_B, and then in a new Interpreter exec modA
> the old version of mod_B is what gets imported. It doesn't seem to
> matter whether I edit mod_A or not.
> Is there something I can do to force the new PythonInterpreter to
> re-read mod_B?
Simply make mod_A start:
reload( mod_B )