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:
parent
46f8e014df
commit
2ff79417c9
17
pep-0221.txt
17
pep-0221.txt
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue