From 01fc25eeb0df8f64ad0fd88e59fd2a2e7fef0e04 Mon Sep 17 00:00:00 2001 From: Barry Warsaw Date: Wed, 23 Aug 2000 05:57:47 +0000 Subject: [PATCH] Minor editorial changes. --- pep-0221.txt | 60 +++++++++++++++++++++++++--------------------------- 1 file changed, 29 insertions(+), 31 deletions(-) diff --git a/pep-0221.txt b/pep-0221.txt index 620a7bd15..4c59fb510 100644 --- a/pep-0221.txt +++ b/pep-0221.txt @@ -1,37 +1,38 @@ PEP: 221 Title: Import As Version: $Revision$ -Owner: thomas@xs4all.net (Thomas Wouters) -Python-Version: 2.0 +Author: thomas@xs4all.net (Thomas Wouters) Status: Accepted -Created: 15-Aug-2000 Type: Standard +Python-Version: 2.0 +Created: 15-Aug-2000 +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 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 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 @@ Rationale 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 @@ Rationale 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 @@ Implementation details 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 @@ Copyright 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