Creating classes and objects more than once?

Carl Banks pavlovevidence at
Sat Nov 29 07:51:59 CET 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
( which imports a Python module (

Near the top of the file, 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 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, 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