[Python-checkins] peps: Minor editorial changes.

georg.brandl python-checkins at python.org
Wed Mar 23 21:26:25 CET 2011


http://hg.python.org/peps/rev/40beece5fef0
changeset:   140:40beece5fef0
user:        Barry Warsaw <barry at python.org>
date:        Wed Aug 23 05:57:47 2000 +0000
summary:
  Minor editorial changes.

files:
  pep-0221.txt |  60 +++++++++++++++++++--------------------
  1 files changed, 29 insertions(+), 31 deletions(-)


diff --git a/pep-0221.txt b/pep-0221.txt
--- a/pep-0221.txt
+++ b/pep-0221.txt
@@ -1,37 +1,38 @@
 PEP: 221
 Title: Import As
 Version: $Revision$
-Owner: thomas at xs4all.net (Thomas Wouters)
+Author: thomas at xs4all.net (Thomas Wouters)
+Status: Accepted
+Type: Standard
 Python-Version: 2.0
-Status: Accepted
 Created: 15-Aug-2000
-Type: Standard
+Post-History:
 
 
 Introduction
 
-    This PEP describes the `import as' proposal for Python 2.0. This
-    PEP tracks the status and ownership of this feature. It contains a
-    description of the feature and outlines changes necessary to
-    support the feature. The CVS revision history of this file
+    This PEP describes the `import as' proposal for Python 2.0.  This
+    PEP tracks the status and ownership of this feature.  It contains
+    a description of the feature and outlines changes necessary to
+    support the feature.  The CVS revision history of this file
     contains the definitive historical record.
 
 
 Rationale
 
-    This PEP proposes a small extention of current Python syntax
-    regarding the `import' and `from <module> import' statements. 
-    These statements load in a module, and either bind that module to
-    a local name, or binds objects from that module to a local name. 
-    However, it is sometimes desirable to bind those objects to a
-    different name, for instance to avoid name clashes. Currently, a
-    round-about way has to be used to achieve this:
+    This PEP proposes an extention of Python syntax regarding the
+    `import' and `from <module> import' statements.  These statements
+    load in a module, and either bind that module to a local name, or
+    binds objects from that module to a local name.  However, it is
+    sometimes desirable to bind those objects to a different name, for
+    instance to avoid name clashes.  This can currently be achieved
+    using the following idiom:
 
         import os
         real_os = os
         del os
     
-    And similar for the `from ... import' statement:
+    And similarly for the `from ... import' statement:
     
         from os import fdopen, exit, stat
         os_fdopen = fdopen
@@ -45,7 +46,7 @@
         from os import fdopen as os_fdopen, exit, stat as os_stat
     
     The `as' name is not intended to be a keyword, and some trickery
-    has to be used to convince the CPython parser it isn't one. For
+    has to be used to convince the CPython parser it isn't one.  For
     more advanced parsers/tokenizers, however, this should not be a
     problem.
     
@@ -54,19 +55,18 @@
     
         import os.path
         
-    The actual name stored locally is `os', not `path' (so that the
-    newly imported module can be referenced as `os.path'.) When
-    introducing the `as' keyword, it is unclear whether the `os'
-    module or the `path' sub-module should be stored `as' the
-    requested local name.
+    The actual name stored locally is `os', not `path', and the newly
+    imported module can be referenced as `os.path'.  When introducing
+    the `as' keyword, it is unclear whether the `os' module or the
+    `path' sub-module should be stored `as' the requested local name.
 
 
 Implementation details
 
     This PEP has been accepted, and the suggested code change has been
-    checked in. The patch can still be found in the SourceForge patch
-    manager[1]. Currently, a NAME field is used in the grammar rather
-    than a bare string, to avoid the keyword issue. It introduces a
+    checked in.  The patch can still be found in the SourceForge patch
+    manager[1].  Currently, a NAME field is used in the grammar rather
+    than a bare string, to avoid the keyword issue.  It introduces a
     new bytecode, IMPORT_STAR, which performs the `from module import
     *' behaviour, and changes the behaviour of the IMPORT_FROM
     bytecode so that it loads the requested name (which is always a
@@ -79,9 +79,9 @@
     into the local namespace.
     
     An additional change to this syntax has also been suggested, to
-    generalize the expression given after the `as' clause. Rather than
-    a single name, it could be allowed to be any expression that
-    yields a valid l-value; anything that can be assigned to. The
+    generalize the expression given after the `as' clause.  Rather
+    than a single name, it could be allowed to be any expression that
+    yields a valid l-value; anything that can be assigned to.  The
     change to accomodate this is minimal, as the patch proves[2], and
     the resulting generalization allows a number of new constructs
     that run completely parallel with other Python assignment
@@ -103,11 +103,9 @@
 
 References
 
-    [1]
-http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
+    [1] http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
 
-    [2]
-http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470
+    [2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470
 
 
 

-- 
Repository URL: http://hg.python.org/peps


More information about the Python-checkins mailing list