Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 221 – Import As

Author:
Thomas Wouters <thomas at python.org>
Status:
Final
Type:
Standards Track
Created:
15-Aug-2000
Python-Version:
2.0
Post-History:


Table of Contents

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 extension 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 accommodate 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 accommodate 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”.

References


Source: https://github.com/python/peps/blob/main/pep-0221.txt

Last modified: 2022-10-05 16:48:43 GMT