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

[SourceForge.net]

Bugs item #992389, was opened at 2004-07-16 11:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992389&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
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: Tim Peters (tim_one)
Date: 2004-11-15 21:03

Message:
Logged In: YES 
user_id=31435

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 06:08

Message:
Logged In: YES 
user_id=1038590

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 10:30

Message:
Logged In: YES 
user_id=31392

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992389&group_id=5470