This is an archive of the discontinued LLVM Phabricator instance.

Enable absolute imports in lldbsuite
ClosedPublic

Authored by zturner on Nov 4 2015, 11:16 AM.

Details

Summary
Enable absolute imports in lldbsuite.

Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3.

When absolute imports are enabled, the import system changes in
a couple of ways:

1) The `import foo` syntax will *only* search sys.path.  If `foo`
   isn't in sys.path, it won't be found.  Period.  Without absolute
   imports, the import system will also search the same directory
   that the importing file resides in, so that you can easily
   import from the same folder.

2) From inside a package, you can use a dot syntax to refer to higher
   levels of the current package.  For example, if you are in the
   package lldbsuite.test.utility, then ..foo refers to
   lldbsuite.test.foo.  You can use this notation with the
   `from X import Y` syntax to write intra-package references.  For
   example, using the previous locationa s a starting point, writing
   `from ..support import seven` would import lldbsuite.support.seven

Since this is now the default behavior in Python 3, this means that
importing from the same directory with `import foo` *no longer works*.
As a result, the only way to have portable code is to force absolute
imports for all versions of Python.

See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more
information about absolute and relative imports.

Diff Detail

Event Timeline

zturner updated this revision to Diff 39222.Nov 4 2015, 11:16 AM
zturner retitled this revision from to Enable absolute imports in lldbsuite.
zturner updated this object.
zturner added a reviewer: tfiala.
zturner added a subscriber: lldb-commits.
tfiala edited edge metadata.Nov 5 2015, 8:41 AM

Does this mean that if we import third party modules, and since you have embedded them into our package, that we would have to change third party code to adhere to our packaging structure? If not, fine. If so, this was one of the areas I mentioned that I was concerned about with the monolithic packaging structure.

Does this mean that if we import third party modules, and since you have embedded them into our package, that we would have to change third party code to adhere to our packaging structure? If not, fine. If so, this was one of the areas I mentioned that I was concerned about with the monolithic packaging structure.

No. I actually explicitly went out of my way to remove the third party packages from our package. That's why they are all in lldb/third_party now. use_lldb_suite adds all the third_party directories to sys.path up front, so you can still use absolute import syntax for this. i.e. import six will still just work, because it's in sys.path.

That said, the only place you have to use relative import syntax is to import stuff from within the same package. Plus, even in the hypothetical case where we did have that, as long as we don't write from future import absolute_import at the top of those packages' modules, they would still continue to work as they normally do.

It took me a while to wrap my head around this PEP, but now that I understand it, I think it's a good thing in principle, since it solves name collisions between your own modules and third-party / system modules by forcing you to make it explicit which one you want. Either you want a system / third-party module (e.g. import foo) or you want a module from within your current package (e.g. from . import foo)

tfiala accepted this revision.Nov 5 2015, 11:19 AM
tfiala edited edge metadata.

Okay, looks good then. Thanks, Zachary!

This revision is now accepted and ready to land.Nov 5 2015, 11:19 AM
zturner closed this revision.Nov 6 2015, 10:21 AM