relative import broken #52150
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = 'https://github.com/brettcannon' closed_at = <Date 2010-08-16.19:11:12.103> created_at = <Date 2010-02-10.19:09:21.579> labels = ['interpreter-core', 'release-blocker'] title = 'relative import broken' updated_at = <Date 2010-08-16.22:44:22.198> user = 'https://bugs.python.org/gangesmaster'
activity = <Date 2010-08-16.22:44:22.198> actor = 'flox' assignee = 'brett.cannon' closed = True closed_date = <Date 2010-08-16.19:11:12.103> closer = 'barry' components = ['Interpreter Core'] creation = <Date 2010-02-10.19:09:21.579> creator = 'gangesmaster' dependencies =  files = ['16201', '16350'] hgrepos =  issue_num = 7902 keywords = ['patch', 'needs review'] message_count = 11.0 messages = ['99176', '99177', '99179', '100006', '106065', '106179', '113926', '114048', '114065', '114067', '114082'] nosy_count = 7.0 nosy_names = ['loewis', 'barry', 'brett.cannon', 'gangesmaster', 'flox', 'meador.inge', 'Oren_Held'] pr_nums =  priority = 'release blocker' resolution = 'fixed' stage = 'resolved' status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue7902' versions = ['Python 2.6']
The text was updated successfully, but these errors were encountered:
the relative-import mechanism is broken... at least on python2.6 but i'd guess on later versions as well.
consider this package layout:
where bar.py is:
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.
I get the same behavior for this reproduction case regardless of whether I use:
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.
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")