On Wed, 19 Apr 2017 04:28 am, Tim Johnson wrote: > Using python 2.7~ > > For testing and edification purposes: > > I have a project which has a controllers package at the directory > level just below the root.
Do you mean the root of the file system? >>From the top-level (root) of the project, I start my python > interpreter. Don't do that. You are defeating the whole purpose of packages. The point of a package is to the caller, it appears like a single library, while still allowing it to contain multiple files internally with its own fine structure. If your package structure looks like this: X/controllers/ +-- __init__.py +-- imp.py ... any other modules and sub-packages then you should start Python from X, not from X/controllers. Or even better, you should ensure X is in sys.path (there are various ways to do that), and then start Python from anywhere. > The packages is called 'controllers' and has a submodule named 'imp' > > I do the following: >>>> a = __import__('imp') >>>> dir(a) > ['C_BUILTIN', 'C_EXTENSION', 'IMP_HOOK', 'NullImporter', > 'PKG_DIRECTORY', ....] > # object a is the builtin imp module Like (nearly) all __dunder__ methods and functions, __import__ is reserved for use by Python and you shouldn't need to use it. The conventional ways to access packages.imp are (untested): # As a user of the controllers package import controllers.imp as a # Within the controllers package from __future__ import absolute_imports from . import imp as a You only need the "from __future__ ..." directive once per module, but it must be the very first line of executable code. (It can only be preceded by blank lines or comments.) To get access to the standard library imp, you do this: # As a user of the controllers package import imp as b # Within the controllers package import imp as b [...] > Now, suppose a python upgrade provides a package called controllers > or there's some great third-party package available called > controllers. If you have two modules/packages with the same name, there's no clean way to access one or the other. That's not how importing works. Whichever module is found in the search path (sys.path) shadows the other. That's both a feature and an annoyance, depend on whether you find it useful or not. But that's how it is. In the case of name conflicts between modules, your choices are: - live with the conflict; - rename the conflicting module; - manually adjust sys.path when and as needed to avoid one and get the other, then reverse your adjustments to do the opposite. I don't recommend the third option. There's no clean way to do it. But if you absolutely must, sys.path is just a list of places to search, you can modify it at will. And sys.modules is just a dict of {name: module} caching the modules, you need to modify that as well. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list