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
|
Title: Import As
|
||||||
Version: $Revision$
|
Version: $Revision$
|
||||||
Author: thomas@xs4all.net (Thomas Wouters)
|
Author: thomas@xs4all.net (Thomas Wouters)
|
||||||
Status: Accepted
|
Status: Final
|
||||||
Type: Standards Track
|
Type: Standards Track
|
||||||
Python-Version: 2.0
|
Python-Version: 2.0
|
||||||
Created: 15-Aug-2000
|
Created: 15-Aug-2000
|
||||||
|
@ -60,8 +60,10 @@ Rationale
|
||||||
|
|
||||||
import os.path as p
|
import os.path as p
|
||||||
|
|
||||||
should store `os.path', not `os', in `p'. The current
|
stores `os.path', not `os', in `p'. This makes it effectively the
|
||||||
implementation does not yet support this.
|
same as
|
||||||
|
|
||||||
|
from os import path as p
|
||||||
|
|
||||||
|
|
||||||
Implementation details
|
Implementation details
|
||||||
|
@ -74,18 +76,21 @@ Implementation details
|
||||||
*' behaviour, and changes the behaviour of the IMPORT_FROM
|
*' behaviour, and changes the behaviour of the IMPORT_FROM
|
||||||
bytecode so that it loads the requested name (which is always a
|
bytecode so that it loads the requested name (which is always a
|
||||||
single name) onto the stack, to be subsequently stored by a STORE
|
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,
|
The special case of `from module import *' remains a special case,
|
||||||
in that it cannot accomodate an `as' clause, and that no STORE
|
in that it cannot accomodate an `as' clause, and that no STORE
|
||||||
opcodes are generated; the objects imported are loaded directly
|
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
|
An additional change to this syntax has also been suggested, to
|
||||||
generalize the expression given after the `as' clause. Rather
|
generalize the expression given after the `as' clause. Rather
|
||||||
than a single name, it could be allowed to be any expression that
|
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
|
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
|
the resulting generalization allows a number of new constructs
|
||||||
that run completely parallel with other Python assignment
|
that run completely parallel with other Python assignment
|
||||||
constructs. However, this idea has been rejected by Guido, as
|
constructs. However, this idea has been rejected by Guido, as
|
||||||
|
|
Loading…
Reference in New Issue