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 bpo-9600. 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 python/cpython#52150.
        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.