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 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