python-peps/pep-0221.txt

110 lines
3.8 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: Draft
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.
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.
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:
- Two bytecode operations would have to be performed, per symbol,
rather than one.
- 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'
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.
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.
Copyright
This document has been placed in the Public Domain.
References
[1]
http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: