Make the PEP conform to reality, and add the suggestion to generalize the

expressions allowed after the 'as' clause. Change some markup, and mark it
as Accepted (which it is, since the change has been checked in.) Barry, this
should probably also change in the PEP Index PEP.

pep-0221.txt

@@ -3,7 +3,7 @@ Title: Import As
 Version: $Revision$
 Owner: thomas@xs4all.net (Thomas Wouters)
 Python-Version: 2.0
-Status: Draft
+Status: Accepted
 Created: 15-Aug-2000
 Type: Standard
 
@@ -49,46 +49,51 @@ 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,
+    
+        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.
+
 
 Implementation details
 
-    A proposed implementation of this new clause can be found in the
+    This PEP has been accepted, and the suggested code change has been
-    SourceForge patch manager[XX]. The patch uses a NAME field in the
+    checked in. The patch can still be found in the SourceForge patch
-    grammar rather than a bare string, to avoid the keyword issue. It
+    manager[1]. Currently, a NAME field is used in the grammar rather
-    also introduces a new bytecode, IMPORT_FROM_AS, which loads an
+    than a bare string, to avoid the keyword issue. It introduces a
-    object from a module and pushes it onto the stack, so it can be
+    new bytecode, IMPORT_STAR, which performs the `from module import
-    stored by a normal STORE_NAME opcode.
+    *' behaviour, and changes the behaviour of the IMPORT_FROM
+    bytecode so that it loads the requested name (which is always a
+    single name) onto the stack, to be subsequently stored by a STORE
+    opcode.
 
     The special case of `from module import *' remains a special case,
-    in that it cannot accomodate an `as' clause. Also, the current
+    in that it cannot accomodate an `as' clause, and that no STORE
-    implementation does not use IMPORT_FROM_AS for the old form of
+    opcodes are generated; the objects imported are loaded directly
-    from-import, even though it would make sense to do so. The reason
+    into the local namespace.
-    for this is that the current IMPORT_FROM bytecode loads objects
-    directly from a module into the local namespace, in one bytecode
-    operation, and also handles the special case of `*'. As a result
-    of moving to the IMPORT_FROM_AS bytecode, two things would happen:
     
-    - Two bytecode operations would have to be performed, per symbol,
+    An additional change to this syntax has also been suggested, to
-      rather than one.
+    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
+    constructs.
 
-    - The names imported through `from-import' would be susceptible to
+        import sys as x['sys']
-      the `global' keyword, which they currently are not. This means
-      that `from-import' outside of the `*' special case behaves more
-      like the normal `import' statement, which already follows the
-      `global' keyword. It also means, however, that the `*' special
-      case is even more special, compared to the ordinary form of
-      `from-import'
 
-    However, for consistency and for simplicity of implementation, it
+        from MyFastcPickle import Pickler as shelve.Pickler
-    is probably best to split off the special case entirely, making a
-    separate bytecode `IMPORT_ALL' that handles the special case of
-    `*', and handle all other forms of `from-import' the way the
-    proposed `IMPORT_FROM_AS' bytecode does.
         
-    This dilemma does not apply to the normal `import' statement,
+        from sys import version_info as (maj, min, pl, relnam, relno)
-    because this is alread split into two opcodes, a `LOAD_MODULE' and a
+        
-    `STORE_NAME' opcode. Supporting the `import as' syntax is a slight
+        from sys import path as mypath[-1:]
-    change to the compiler only.
 
 
 Copyright
@@ -101,6 +106,9 @@ References
     [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
+
 
 
 Local Variables: