En Sat, 29 Nov 2008 04:51:59 -0200, Carl Banks <[EMAIL PROTECTED]>
escribió:
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.
While all the above explanation is true for scripts executed using "python
xxx.py", it's not the same when you execute a module using runpy.py, that
is, using "python -m xxx"
If you execute a module inside a package in that way, Python recognizes
the fact it's inside a package, and honors relative imports (starting from
version 2.6, when PEP366 was implemented).
So the statement "from __future__ import absolute_import" *does* change
how imports are handled on the top module.
A simple test showing the difference:
C:\temp\test366>dir /b
b.py
pkga
C:\temp\test366>type b.py
msg='this is the external b module'
C:\temp\test366>cd pkga
C:\temp\test366\pkga>dir /b
abs.py
b.py
rel.py
__init__.py
C:\temp\test366\pkga>type __init__.py
C:\temp\test366\pkga>type b.py
msg='this is the b module inside package pkga'
C:\temp\test366\pkga>type rel.py
print "this script uses 'traditional' import semantics"
from b import msg
print msg
print "using a bare import:"
import b
print b.msg
C:\temp\test366\pkga>type abs.py
from __future__ import absolute_import
print "this script sets absolute_import"
print "using an absolute import:"
from b import msg
print msg
print "using a bare import:"
import b
print b.msg
print "using an explicit relative import:"
from .b import msg
print msg
C:\temp\test366\pkga>cd ..
C:\temp\test366>python -m pkga.rel
this script uses 'traditional' import semantics
this is the b module inside package pkga
using a bare import:
this is the b module inside package pkga
C:\temp\test366>python -m pkga.abs
this script sets absolute_import
using an absolute import:
this is the external b module
using a bare import:
this is the external b module
using an explicit relative import:
this is the b module inside package pkga
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
