[ python-Bugs-992389 ] attribute error after non-from import

SourceForge.net noreply at sourceforge.net
Mon Jul 3 14:38:42 CEST 2006

Bugs item #992389, was opened at 2004-07-16 17:09
Message generated for change (Comment added) made by loewis
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: attribute error after non-from import

Initial Comment:
This bug applied to 2.3 and 2.4. It probably applies to
earlier versions, but who cares? :)

Under some circumstances, code like:

  import eek.foo.baz
  y = eek.foo.baz.y

fails with an attribute error for "foo" if foo is still
being imported.

I've attached a zip file of a demo package "eek" that
demonstrates the problem.  If you unzip the package and:

  import eek.foo

you'll get the attribute error described above.

I think the problem is that eek's foo attribute isn't
set until the import of foo is finished.  This is too late.


>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-03 14:38

Logged In: YES 

Lowering the priority, as this apparently is not a
high-priority issue.


Comment By: Tim Peters (tim_one)
Date: 2004-11-16 03:03

Logged In: YES 

Nick, the semantics of circular imports aren't clear even if no 
packages are involved.  Note that the Reference manual is 
silent about such cases.  In effect, it's defined by the 
implementation, and some people think they know how that 
works -- although nobody has credibly claimed to fully 
understand the implementation consequences since Gordon 
McMillan vanished <0.5 wink>.

While I expect this bug report to sit here for years (it's hard 
to imagine anyone caring enough to devote the time needed 
to untangle this subsystem), I'll note in passing that this 
case "works" if bar.py uses relative import instead; i.e., if it 
begins with

import baz
y = baz.y

instead of with

import eek.foo.baz
y = eek.foo.baz.y

Then it stops referencing attributes that don't exist before 
the whole chain of imports completes.


Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-15 12:08

Logged In: YES 

If the semantics aren't clear, then isn't that a bug in
itself? If the behaviour of Jim's code is officially
undefined, then the docs need to say so.

A simple rule would seem to be "a package should not try to
import itself or any subpackages with an absolute import in
its __init__.py file".

Given the nature of __all__ and __path__ for packages, I
can't see a way to safely set eek's foo attribute before
foo's __init__.py has been processed.


Comment By: Jeremy Hylton (jhylton)
Date: 2004-11-07 16:30

Logged In: YES 

Are the semantics of import clear enough to confirm that
this is a bug?  Specifically, this seems to revolve around
circular imports and code in __init__.  I agree that this
behavior is confusing, but I don't know if that has more to
do with the nature of circular imports than any bug.


You can respond by visiting: 

More information about the Python-bugs-list mailing list