Re: [SQLObject] Preventing Duplicate Class Definitions

[Ian B. <ia...@co...>]

Luke Opperman wrote:
> I'll see if I can get a unit test together to illustrate a problem I've 
> been
> having, but here's the scenario (may be a python import issue that we can't
> get around either, I recall problems with imports with different import 
> lines,
> but here the lines at least look the same...)
> 
> File structure:
> 
> ./  <-- webware py/psps mostly live here, importing Objects.X
> ./Objects  <-- primarily SQLObjects
> ./Objects/Core  <-- a few central things here, where the problem is.
> 
> the absolute path to ./ is in PYTHONPATH.
> 
> So both a psp/py in ./ and a script in ./Objects/Core use an import line 
> like:
> 
> from Objects.User import User
> 
> but this leads to a duplicate class error from SQLObject.
> 
> The full import pattern looks like:
> 
> ./Page.py -> from Objects.User import User
> ./Objects.User is imported
> ./Page.py -> from Objects.Core.CheckUser import CheckUser
> ./Objects/Core/CheckUser.py -> from Objects.User import User
> 
> Note, this is on an existing app using 0.5, I'll try to get some time to 
> track
> it down further next week.

I think this is a problem that has occurred with Webware a number of 
times, mostly as a side effect when the path gets complicated and 
redundant.  I think Python will import a file as two separate modules, 
if it finds the module in different ways.  E.g., if /path and 
/path/inner are both in sys.path, and in one place you import 
inner.module and the other you just import module, you'll get two modules.

I'm not clear exactly when this happens, it's subtle.  I would recommend 
printing out both module objects, and seeing if their IDs match.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org