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

[Ian Kelly]

On Thu, Dec 15, 2011 at 7:34 AM, Nathan Rice
<nathan.alexander.rice at gmail.com> 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?

I think this may be the same problem that the poster in this thread encountered:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/961a90219a61e19d/9ed06601603b58d4

Normally I believe the __module__ attribute should be fully qualified
regardless of whether the import was absolute or relative.  That
you're not seeing this suggests that the "relative" import may
actually be an absolute import starting from a different sys.path
entry.