[Python-checkins] r56172 - peps/trunk/pep-0366.txt

[nick.coghlan]

Author: nick.coghlan
Date: Wed Jul  4 14:47:13 2007
New Revision: 56172

Modified:
   peps/trunk/pep-0366.txt
Log:
Typo fixes, note limitation of direct execution boilerplate

Modified: peps/trunk/pep-0366.txt
==============================================================================
--- peps/trunk/pep-0366.txt	(original)
+++ peps/trunk/pep-0366.txt	Wed Jul  4 14:47:13 2007
@@ -18,9 +18,9 @@
 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 @@
 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 @@
   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