[Python-checkins] peps: Minor editorial changes.
georg.brandl
python-checkins at python.org
Wed Mar 23 21:26:25 CET 2011
http://hg.python.org/peps/rev/40beece5fef0
changeset: 140:40beece5fef0
user: Barry Warsaw <barry at python.org>
date: Wed Aug 23 05:57:47 2000 +0000
summary:
Minor editorial changes.
files:
pep-0221.txt | 60 +++++++++++++++++++--------------------
1 files changed, 29 insertions(+), 31 deletions(-)
diff --git a/pep-0221.txt b/pep-0221.txt
--- a/pep-0221.txt
+++ b/pep-0221.txt
@@ -1,37 +1,38 @@
PEP: 221
Title: Import As
Version: $Revision$
-Owner: thomas at xs4all.net (Thomas Wouters)
+Author: thomas at xs4all.net (Thomas Wouters)
+Status: Accepted
+Type: Standard
Python-Version: 2.0
-Status: Accepted
Created: 15-Aug-2000
-Type: Standard
+Post-History:
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
+ 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:
+ 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 similar for the `from ... import' statement:
+ And similarly for the `from ... import' statement:
from os import fdopen, exit, stat
os_fdopen = fdopen
@@ -45,7 +46,7 @@
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
+ 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.
@@ -54,19 +55,18 @@
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.
+ The actual name stored locally is `os', not `path', and 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
+ 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
@@ -79,9 +79,9 @@
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
+ 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
@@ -103,11 +103,9 @@
References
- [1]
-http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
+ [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
+ [2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list