iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor editorial changes.

This commit is contained in:
Barry Warsaw 2000-08-23 05:57:47 +00:00
parent 64fe351eed
commit 01fc25eeb0
1 changed files with 29 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
pep-0221.txt
View File

@ -1,37 +1,38 @@
PEP: 221 PEP: 221
Title: Import As Title: Import As
Version: $Revision$ Version: $Revision$
Owner: thomas@xs4all.net (Thomas Wouters) Author: thomas@xs4all.net (Thomas Wouters)
Python-Version: 2.0
Status: Accepted Status: Accepted
Created: 15-Aug-2000
Type: Standard Type: Standard
Python-Version: 2.0
Created: 15-Aug-2000
Post-History:
Introduction Introduction
This PEP describes the `import as' proposal for Python 2.0. This This PEP describes the `import as' proposal for Python 2.0. This
PEP tracks the status and ownership of this feature. It contains a PEP tracks the status and ownership of this feature. It contains
description of the feature and outlines changes necessary to a description of the feature and outlines changes necessary to
support the feature. The CVS revision history of this file support the feature. The CVS revision history of this file
contains the definitive historical record. contains the definitive historical record.
Rationale Rationale
This PEP proposes a small extention of current Python syntax This PEP proposes an extention of Python syntax regarding the
regarding the `import' and `from <module> import' statements. `import' and `from <module> import' statements. These statements
These statements load in a module, and either bind that module to load in a module, and either bind that module to a local name, or
a local name, or binds objects from that module to a local name. binds objects from that module to a local name. However, it is
However, it is sometimes desirable to bind those objects to a sometimes desirable to bind those objects to a different name, for
different name, for instance to avoid name clashes. Currently, a instance to avoid name clashes. This can currently be achieved
round-about way has to be used to achieve this: using the following idiom:
import os import os
real_os = os real_os = os
del os del os
And similar for the `from ... import' statement: And similarly for the `from ... import' statement:
from os import fdopen, exit, stat from os import fdopen, exit, stat
os_fdopen = fdopen os_fdopen = fdopen
@ -45,7 +46,7 @@ Rationale
from os import fdopen as os_fdopen, exit, stat as os_stat 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 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 has to be used to convince the CPython parser it isn't one. For
more advanced parsers/tokenizers, however, this should not be a more advanced parsers/tokenizers, however, this should not be a
problem. problem.
@ -54,19 +55,18 @@ Rationale
import os.path import os.path
The actual name stored locally is `os', not `path' (so that the The actual name stored locally is `os', not `path', and the newly
newly imported module can be referenced as `os.path'.) When imported module can be referenced as `os.path'. When introducing
introducing the `as' keyword, it is unclear whether the `os' the `as' keyword, it is unclear whether the `os' module or the
module or the `path' sub-module should be stored `as' the `path' sub-module should be stored `as' the requested local name.
requested local name.
Implementation details Implementation details
This PEP has been accepted, and the suggested code change has been This PEP has been accepted, and the suggested code change has been
checked in. The patch can still be found in the SourceForge patch checked in. The patch can still be found in the SourceForge patch
manager[1]. Currently, a NAME field is used in the grammar rather manager[1]. Currently, a NAME field is used in the grammar rather
than a bare string, to avoid the keyword issue. It introduces a than a bare string, to avoid the keyword issue. It introduces a
new bytecode, IMPORT_STAR, which performs the `from module import new bytecode, IMPORT_STAR, which performs the `from module import
*' behaviour, and changes the behaviour of the IMPORT_FROM *' behaviour, and changes the behaviour of the IMPORT_FROM
bytecode so that it loads the requested name (which is always a bytecode so that it loads the requested name (which is always a
@ -79,9 +79,9 @@ Implementation details
into the local namespace. into the local namespace.
An additional change to this syntax has also been suggested, to An additional change to this syntax has also been suggested, to
generalize the expression given after the `as' clause. Rather than generalize the expression given after the `as' clause. Rather
a single name, it could be allowed to be any expression that 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 yields a valid l-value; anything that can be assigned to. The
change to accomodate this is minimal, as the patch proves[2], and change to accomodate this is minimal, as the patch proves[2], and
the resulting generalization allows a number of new constructs the resulting generalization allows a number of new constructs
that run completely parallel with other Python assignment that run completely parallel with other Python assignment
@ -103,11 +103,9 @@ Copyright
References References
[1] [1] http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
[2] [2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470
http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470