Creating classes and objects more than once?
Carl Banks
pavlovevidence at gmail.com
Sat Nov 29 01:51:59 EST 2008
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
More information about the Python-list
mailing list