| Submitter | mercurial-bugs@selenic.com |
|---|---|
| Date | Sept. 6, 2013, 2:22 a.m. |
| Message ID | <bug-4029-285@http.bz.selenic.com/> |
| Download | mbox | patch |
| Permalink | /patch/2387/ |
| State | Not Applicable |
| Headers | show |
Comments
Patch
diff -r 1d07bf106c2a mercurial/demandimport.py --- a/mercurial/demandimport.py Wed Sep 04 18:42:55 2013 -0700 +++ b/mercurial/demandimport.py Thu Sep 05 22:11:20 2013 -0400 @@ -55,7 +55,9 @@ def _load(self): if not self._module: head, globals, locals, after = self._data - mod = _origimport(head, globals, locals) + if 'absolute_import' in locals: + level = 0 + mod = _origimport(head, globals, locals, [], level) # load submodules def subload(mod, p): h, t = p, None
http://bz.selenic.com/show_bug.cgi?id=4029 Priority: normal Bug ID: 4029 CC: mercurial-devel@selenic.com Assignee: bugzilla@selenic.com Summary: demandimport doesn't honor absolute_import Severity: bug Classification: Unclassified OS: Windows Reporter: jaraco@jaraco.com Hardware: PC Status: UNCONFIRMED Version: 2.7.1 Component: Mercurial Product: Mercurial In https://bitbucket.org/Mekk/mercurial_keyring/issue/31/failed-to-import-extension, it became apparent that the demand import machinery doesn't honor the 'absolute_import' directive. If a relative import is present, it is given preference even if the module author has indicated absolute_import from __future__. I believe the fix is pretty straightforward. I've tested this against the reported issue and it fixes the failure (and imports the correct module from the root namespace). Please consider committing this patch. Thanks.