python-peps/pep-0221.txt

118 lines
3.9 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

PEP: 221
Title: Import As
Version: $Revision$
Owner: thomas@xs4all.net (Thomas Wouters)
Python-Version: 2.0
Status: Accepted
Created: 15-Aug-2000
Type: Standard
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 a small extention of current 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. Currently, a
round-about way has to be used to achieve this:
import os
real_os = os
del os
And similar 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.
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
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, and that no STORE
opcodes are generated; the objects imported are loaded directly
into the local namespace.
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.
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:]
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
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: