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
-    SourceForge patch manager[XX]. The patch uses a NAME field in the
-    grammar rather than a bare string, to avoid the keyword issue. It
-    also introduces a new bytecode, IMPORT_FROM_AS, which loads an
-    object from a module and pushes it onto the stack, so it can be
-    stored by a normal STORE_NAME opcode.
+    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
+    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
+    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
-    implementation does not use IMPORT_FROM_AS for the old form of
-    from-import, even though it would make sense to do so. The reason
-    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:
+    in that it cannot accomodate an `as' clause, and that no STORE
+    opcodes are generated; the objects imported are loaded directly
+    into the local namespace.
     
-    - Two bytecode operations would have to be performed, per symbol,
-      rather than one.
+    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
+    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
-      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'
+        import sys as x['sys']
 
-    However, for consistency and for simplicity of implementation, it
-    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.
+        from MyFastcPickle import Pickler as shelve.Pickler
         
-    This dilemma does not apply to the normal `import' statement,
-    because this is alread split into two opcodes, a `LOAD_MODULE' and a
-    `STORE_NAME' opcode. Supporting the `import as' syntax is a slight
-    change to the compiler only.
+        from sys import version_info as (maj, min, pl, relnam, relno)
+        
+        from sys import path as mypath[-1:]
 
 
 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: