Bring PEP up to date, and emphasise that 'from module import name' now

follows the 'global' directive, but 'from module import *' does not. Mark as
'Final'.
This commit is contained in:
Thomas Wouters 2000-09-23 12:00:37 +00:00
parent 46f8e014df
commit 2ff79417c9
1 changed files with 11 additions and 6 deletions

View File

@ -2,7 +2,7 @@ PEP: 221
Title: Import As
Version: $Revision$
Author: thomas@xs4all.net (Thomas Wouters)
Status: Accepted
Status: Final
Type: Standards Track
Python-Version: 2.0
Created: 15-Aug-2000
@ -60,8 +60,10 @@ Rationale
import os.path as p
should store `os.path', not `os', in `p'. The current
implementation does not yet support this.
stores `os.path', not `os', in `p'. This makes it effectively the
same as
from os import path as p
Implementation details
@ -74,18 +76,21 @@ Implementation details
*' behaviour, and changes the behaviour of the IMPORT_FROM
bytecode so that it loads the requested name (which is always a
single name) onto the stack, to be subsequently stored by a STORE
opcode.
opcode. As a result, all names explicitly imported now follow the
`global' directives.
The special case of `from module import *' remains a special case,
in that it cannot accomodate an `as' clause, and that no STORE
opcodes are generated; the objects imported are loaded directly
into the local namespace.
into the local namespace. This also means that names imported in
this fashion are always local, and do not follow the `global'
directive.
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
change to accomodate this is minimal, as the patch proves[2], and
change to accomodate this is minimal, as the patch[2] proves, and
the resulting generalization allows a number of new constructs
that run completely parallel with other Python assignment
constructs. However, this idea has been rejected by Guido, as