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
    contains the definitive historical record.

Rationale

    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 similarly for the `from ... import' statement:
    
        from os import fdopen, exit, stat
        os_fdopen = fdopen
        os_stat = stat
        del fdopen, stat
    
    The proposed syntax change would add an optional `as' clause to
    both these statements, as follows:

        import os as real_os
        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
    more advanced parsers/tokenizers, however, this should not be a
    problem.

    A slightly special case exists for importing sub-modules.  The
    statement

        import os.path    

    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

    stores `os.path', not `os', in `p'.  This makes it effectively the
    same as
    
        from os import path as p

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
    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. As a result, all names explicitly imported now follow the
    `global' directives.

    The special case of `from module import *' remains a special case,
    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. This also means that names imported in
    this fashion are always local, and do not follow the `global'
    directive.
    
    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[2] proves, and
    the resulting generalization allows a number of new constructs
    that run completely parallel with other Python assignment
    constructs. However, this idea has been rejected by Guido, as
    `hypergeneralization'.

Copyright

    This document has been placed in the Public Domain.

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