the relative-import mechanism is broken... at least on python2.6 but i'd guess on later versions as well.
consider this package layout:
    /tmp/foo/
    /tmp/foo/__init__.py
    /tmp/foo/bar.py
where bar.py is:
    # note this is a relative import and should fail!
    from .os import walk
    print walk
    # and this should also fail
    from . import os
    print os
running it yields a bug:
$ PYTHONPATH="/tmp" python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo.bar
<function walk at 0xb7d2aa04>  # <<<< ?!?!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/foo/bar.py", line 4, in <module>
    from . import os
ImportError: cannot import name os
"from . import os" fails as expected, but "from .os import walk" works -- although it should obviously fail too.
-tomer

i believe brett is in charge of this, adding him to the noisy. sorry if it's not you :)

So doing the import manually through __import__('os', globals(), locals(), ['walk'], 1) does not work. My guess is it has something to do with the IMPORT_FROM opcode (or something related), but I don't have time right now to dig deeper.

> So doing the import manually through __import__('os', globals(),
> locals(), ['walk'], 1) does not work.
I get the same behavior for this reproduction case regardless of whether I use:
   import .os import walk
or:
   __import__('os', globals(), locals(), ['walk'], 1)
The bug is reproducible in the trunk.
I think the problem has to do with 'import_module_level' incorrectly doing an absolute lookup for 'os' when the relative lookup in 'foo' fails.  I have attached a patch with the relevant fix and test case.

Does this patch seem reasonable?

Thanks for the patch, Meador. All I did was tweak the test slightly. Committed in:
+ 2.7: r81380
+ 2.6: r81381

Backporting this change to 2.6 has created an incompatibility in that branch, see for example issue9600. Apparently, it will only break code that is "conceptually wrong", but still "worked" on 2.6.
I'll suggest that this is a release-critical issue for 2.6.6. It should be considered whether the incompatibility is accepted, or fixed, or reverted.

Btw, the comment and failure message in r81380/r81381 look wrong.
-    # If absolute import syntax is used, then do not try to perform
-    # a relative import in the face of failure.
+    # If explicit relative import syntax is used, then do not try
+    # to perform an absolute import in the face of failure.
     self.fail("explicit relative import triggered "
-              "an implicit relative import")
+              "an implicit absolute import")
In addition the TestCase.assertRaises method could be used:
    def test_absolute_import_without_future(self):
        # If explicit relative import syntax is used, then do not try
        # to perform a relative import in the face of failure.
        # Issue #7902.
        with self.assertRaises(ImportError):
            from .os import sep
            self.fail("explicit relative import triggered an "
                      "implicit absolute import")

Comment changed in r84097, 3.2 branch, with minor fixes.

Guido has spoken: http://mail.python.org/pipermail/python-dev/2010-August/103104.html
We'll keep the change for 2.6.6rc2.

Merged in 3.1 with r84115.

stage: patch review -> resolved

nosy: + meador.inge
messages: + msg100006

keywords: + patch