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

[david.goodger]

Author: david.goodger
Date: Fri Aug  3 21:19:44 2007
New Revision: 56710

Modified:
   peps/trunk/pep-0366.txt
Log:
markup fixes

Modified: peps/trunk/pep-0366.txt
==============================================================================
--- peps/trunk/pep-0366.txt	(original)
+++ peps/trunk/pep-0366.txt	Fri Aug  3 21:19:44 2007
@@ -20,7 +20,7 @@
 between PEP 328 and PEP 338.
 
 By adding a new module level attribute, this PEP allows relative imports
-to work automatically if the module is executed using the ``-m``switch.
+to work automatically if the module is executed using the ``-m`` switch.
 A small amount of boilerplate in the module itself will allow the relative
 imports to work when the file is executed by name.
 
@@ -48,7 +48,7 @@
 ``__package__`` attribute will be set to the empty string. To allow
 relative imports when the module is executed directly, boilerplate
 similar to the following would be needed before the first relative
-import statement:
+import statement::
 
   if __name__ == "__main__" and not __package_name__:
       __package_name__ = "<expected_pacakage_name>"
@@ -68,9 +68,9 @@
 ====================
 
 The current inability to use explicit relative imports from the main
-module is the subject of at least one open SF bug report (#1510172)[1],
+module is the subject of at 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]).
+comp.lang.python (such as Alan Isaac's question in [2]_).
 
 This PEP is intended to provide a solution which permits explicit
 relative imports from main modules, without incurring any significant
@@ -85,7 +85,7 @@
 
 Rev 47142 in SVN implemented an early variant of this proposal
 which stored the main module's real module name in the
-'__module_name__' attribute. It was reverted due to the fact
+``__module_name__`` attribute. It was reverted due to the fact
 that 2.5 was already in beta by that time.
 
 A new patch will be developed for 2.6, and forward ported to
@@ -98,7 +98,7 @@
 PEP 3122 proposed addressing this problem by changing the way
 the main module is identified. That's a significant compatibility cost
 to incur to fix something that is a pretty minor bug in the overall
-scheme of things, and the PEP was rejected [3].
+scheme of things, and the PEP was rejected [3]_.
 
 The advantage of the proposal in this PEP is that its only impact on
 normal code is the small amount of time needed to set the extra