Odd behavior of object equality/identity in the context of relative vs fully qualified imports

[Dave Angel]

On 12/15/2011 09:34 AM, Nathan Rice wrote:
> I just ran into this yesterday, and I am curious if there is a
> rational behind it...
>
> I have a class that uses a dictionary to dispatch from other classes
> (k) to functions for those classes (v).  I recently ran into a bug
> where the dictionary would report that a class which was clearly in
> the dictionary's keys was giving a KeyError.  id() produced two
> distinct values, which I found to be curious, and
> issubclass/isinstance tests also failed.  When I inspected the two
> classes, I found that the only difference between the two was the
> __module__ variable, which in one case had a name relative to the
> current module (foo), and in another case had the fully qualified name
> (bar.foo).  When I went ahead and changed the import statement for the
> module to import bar.foo rather than import foo, everything worked as
> expected.  My first thought was that I had another foo module in an
> old version of the bar package somewhere on my pythonpath;  After a
> thorough search this proved not to be the case.
>
> Has anyone else run into this?  Is this intended behavior?  If so, why?
>
> Nathan
Hard to tell with such generic information.  But I'm guessing you 
imported your script from some other module, creating a circular import 
sequence.  The circular can be a problem in its own right.  But even 
worse, if the script is part of the chain is that it's loaded twice, 
with different names.  And any top-level items, such as classes, will be 
instantiated twice as well.  is your script called foo.py by any chance?

-- 

DaveA