On Nov 28, 11:51 pm, Carl Banks > Absolute versus relative imports don't have anything to do with the > issue here. PEP 328 concerns itself with imports relative to the > executing module in package space. It has nothing to do with imports > relative to the current directory in filename space.
I thought of another way to put this to help explain things. Suppose you have two files in your current directory, a Python script file (app.py) which imports a Python module (work.py). Near the top of the file app.py, there is line like this: import work What happens beneath the covers when this statement is excuted (and from __future__ import absolute_import hasn't been run)? Many people seem to think that the Python interpreter first considers whether this is a relative import and starts by looking for "sister" modules in the same "package" (i.e., directory). Python would thus see the file work.py in the same "package" and complete this as a relative import. Thus, they reason, if one were to add "from __future__ import absolute_import" to the top of app.py, the import would no longer work because implicit relative imports have been disabled. One would have to use "from . import work" instead. Well, this is not how it happens. No top level module, including __main__, is in a package. Thus, when Python sees "import work" in a top-level module, it doesn't consider it to be a relative import, even when implicit relative imports have not been disabled. The point of this is, disabling implicit relative imports has no effect on imports from top-level modules since they were never relative imports anyway. Python is able to find the "sisters" of top- level modules and scripts not because it is doing a relative import, but because those "sister" modules are in one of the directories listed in sys.path. In particular, if "" is listed in sys.path, the current working directory--even when modified by os.chdir--will be searched for "sisters" of top-level modules. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
