Minor editorial changes.
This commit is contained in:
Barry Warsaw
parent
64fe351eed
commit
01fc25eeb0
60
pep-0221.txt
60
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 <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 @@ 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
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue