Duplicate modules problem

[Chuck Esterbrook]

At 03:34 PM 2/23/2001 -0500, Terrel Shumway wrote:
>Chuck Esterbrook wrote:
>
> > In summary, the problem is that when launching a program from within a
> > Python package, confusion can result about paths of modules resulting in
> > duplicate modules residing in memory (and therefore duplication classes
> > (and therefore problems with isinstance())).
> >
> > The solution was to provide a Launch.py program that essentially does an
> > "os.chdir(os.pardir))" before importing the package, its
> > "starter" module and invoking main().
>
>I don't understand why this is necessary.  It seems much cleaner to me to 
>just be careful about sys.path and use the correct import statements.

Um, I never had any incorrect or abusive use of import statements.

When a file sat in the same directory, I said:
   from Foo import Foo

When it sat in an external package, I said:
   from Pkg.Foo import Foo

I learned these conventions from Python. I didn't invent them.

Perhaps I had an "incorrect" situation if it was never intended that 
programs start out of their own packages.


> > Also, a "if '' not in sys.path: sys.path.insert(0, '')" was needed to fix
> > problems when starting with "Launch.py" rather than "python Launch.py".
> >
>
>Please explain this problem. Can you show us Lauch.py and examples of its use?

You can get it from CVS:
https://sourceforge.net/cvs/?group_id=4866

See WebKit/Launch.py.


Again, the problem is when running a program out of a package. And if you 
don't mind duplicate modules, you don't need the fix. But duplicates 
eventually lead to subtle, arcane bugs. We need the fix in WebKit.

See more below.


>I think having "" in sys.path is just asking for trouble, but oh well -- 
>leave it in if you like.  The ManufactureWare/FactoryKit/main.py works 
>fine if you correct the broken import statement. __main__ is not part of 
>the package and cannot use the relative import shortcut:  "from FactoryKit 
>import Factory" is the correct import.  Removing "" from sys.path just 
>makes the breakage more visible.

Regarding the import, the fix does what you describe: Makes the package 
explicit to the program.


Regarding '' in sys.path, if you say:
   > python someprog.py

you get '' as the first element in the path. Again that's Python, not me.

However, if you say:
   > someprog.py

then you get an absolute path in place of ''. Geoff ran into this first and 
it caused problems, hence the fix. Since the fix puts you back to the 
sys.path you would have gotten from Python anyway (by launching 
differently), it doesn't feel so evil to me.

Regarding my choice of:
   os.chdir(os.pardir)

I could done something like this instead:
   sys.path.insert(1, os.path.abspath(os.pardir))

The first seemed a tad simpler.

Also, regarding the use of Launch.py, I might have chosen to bake this 
directly into the app server, BUT the problem is that we have at least 2 of 
them and will be adding another in the future. Also, Launch.py is a very 
small, very clean file, making it easier to deal with independent of all 
that goes on inside the app server source files.


I have been flexing the plug-ins, examples and test cases for WebKit and 
things are working good. At the very least, they're working much better 
than before, even if Launch.py doesn't suit your taste.

The standard way to launch the app server is still:

 > cd Webware/WebKit
 > ./AppServer


-Chuck
--
Get web dev at http://webware.sourceforge.net/