Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17282 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Odd behavior of object equality/identity in the context of relative vs fully qualified imports Nathan Rice <nathan.alexander.rice@gmail.com> - 2011-12-15 12:11 -0500

#17282 — Re: Odd behavior of object equality/identity in the context of relative vs fully qualified imports

It would be more work than I want to go into to provide full context
(unless it is to file a bug report, if it actually is a bug).  I
verified that there are no cyclical dependency issues using snakefood,
and I doublechecked that just changing the import from full to partial
name is sufficient to reintroduce the bug.

Can I get confirmation that this is not expected behavior?  I will go
ahead and file a bug report it that is the case.

Nathan

On Thu, Dec 15, 2011 at 10:08 AM, Dave Angel <d@davea.name> wrote:
> 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
>

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web