iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Typo fixes, note limitation of direct execution boilerplate

This commit is contained in:
Nick Coghlan 2007-07-04 12:47:13 +00:00
parent b97dfc0f1f
commit c1e4e15c12
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
pep-0366.txt
View File

@ -18,9 +18,9 @@ This PEP proposes a backwards compatible mechanism that permits
the use of explicit relative imports from executable modules within
packages. Such imports currently fail due to an awkward interaction
between PEP 328 and PEP 338 - this behaviour is the subject of at
least one open SF bug report (#1510172)[1], and has lead to at least
a few queries on comp.lang.python (such as Alan Isaac's question in
[2]).
least one open SF bug report (#1510172)[1], and has most likely
been a factor in at least a few queries on comp.lang.python (such
as Alan Isaac's question in [2]).
With the proposed mechanism, relative imports will work automatically
if the module is executed using the ``-m`` switch. A small amount of
@ -55,8 +55,8 @@ executed (e.g. test modules or utility scripts).
For the 2.5 release, the recommendation is to always use absolute
imports in any module that is intended to be used as a main module.
The ``-m`` switch already provides a benefit here, as it inserts the
current directory into ``sys.path``, instead of the directory contain the
main module. This means that it is possible to run a module from
current directory into ``sys.path``, instead of the directory containing
the main module. This means that it is possible to run a module from
inside a package using ``-m`` so long as the current directory contains
the top level directory for the package. Absolute imports will work
correctly even if the package isn't installed anywhere else on
@ -135,10 +135,15 @@ the top of the script::
if __name__ == "__main__" and not __package_name__:
__package_name__ = "<expected_pkg_name>"
Note that this boilerplate has the same disadvantage as the use of
absolute imports of sibling modules - if the script is moved to a
different package or subpackage, the boilerplate will need to be
updated manually.
Note that this boilerplate is sufficient only if the top level package
is already accessible via sys.path. Additional code that manipulates
sys.path would be needed in order for direct execution to work
without the top level package already being on sys.path.
This approach also has the same disadvantage as the use of absolute
imports of sibling modules - if the script is moved to a different
package or subpackage, the boilerplate will need to be updated
manually.
With this feature in place, the test scripts in the package above
would be able to change their import lines to something along the