Clean up a few items: the 'import os.path as p' syntax and the

'extended-as'-assignment syntax, both of which Guido has decided on.

pep-0221.txt

@@ -3,7 +3,7 @@ Title: Import As
 Version: $Revision$
 Author: thomas@xs4all.net (Thomas Wouters)
 Status: Accepted
-Type: Standard
+Type: Standards Track
 Python-Version: 2.0
 Created: 15-Aug-2000
 Post-History:
@@ -50,15 +50,18 @@ Rationale
     more advanced parsers/tokenizers, however, this should not be a
     problem.
 
-    To avoid confusion, importing a submodule `as' another module is
-    not allowed. When importing a submodule in the normal way,
+    A slightly special case exists for importing sub-modules.  The
+    statement
 
         import os.path    
 
-    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.
+    stores the module `os' locally as `os', so that the imported
+    submodule `path' is accessible as `os.path'.  As a result,
+    
+        import os.path as p
+
+    should store `os.path', not `os', in `p'.  The current
+    implementation does not yet support this.
 
 
 Implementation details
@@ -85,15 +88,8 @@ Implementation details
     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
-    constructs.
-
-        import sys as x['sys']
-
-        from MyFastcPickle import Pickler as shelve.Pickler
-        
-        from sys import version_info as (maj, min, pl, relnam, relno)
-        
-        from sys import path as mypath[-1:]
+    constructs. However, this idea has been rejected by Guido, as
+    `hypergeneralization'.
 
 
 Copyright