--QKdGvSO+nmPlgiQ/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I wrote a quick PEP describing the 'import as' proposal I posted a patch for
last week. Mostly since I was bored in the train to work (too many kids running
around to play Diablo II or any other game -- I hate it when those brats go
'oh cool' and keep hanging around looking over my shoulder ;-) but also a
bit because Tim keeps insisting it should be easy to write a PEP. Perhaps
lowering the standard by providing a few *small* PEPs helps with that ;)
Just's 'indexing-for' PEP would be a good one, too, in that case.
Anyway, the proto-PEP is attached. It's in draft status as far as I'm
concerned, but the PEP isn't really necessary if the feature is accepted by
acclamation.
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
--QKdGvSO+nmPlgiQ/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pep-02XX.txt"
PEP: 2XX
Title: Import As
Version: $Revision: 1.0 $
Owner: thomas@xs4all.net (Thomas Wouters)
Python-Version: 2.0
Status: Draft
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
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:
import os
real_os = os
del os
And similar for the `from ... import' statement:
from os import fdopen, exit, stat
os_fdopen = fdopen
os_stat = stat
del fdopen, stat
The proposed syntax change would add an optional `as' clause to
both these statements, as follows:
import os as real_os
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
more advanced parsers/tokenizers, however, this should not be a
problem.
Implementation details
A proposed implementation of this new clause can be found in the
SourceForge patch manager[XX]. The patch uses a NAME field in the
grammar rather than a bare string, to avoid the keyword issue. It
also introduces a new bytecode, IMPORT_FROM_AS, which loads an
object from a module and pushes it onto the stack, so it can be
stored by a normal STORE_NAME opcode.
The special case of `from module import *' remains a special case,
in that it cannot accomodate an `as' clause. Also, the current
implementation does not use IMPORT_FROM_AS for the old form of
from-import, even though it would make sense to do so. The reason
for this is that the current IMPORT_FROM bytecode loads objects
directly from a module into the local namespace, in one bytecode
operation, and also handles the special case of `*'. As a result
of moving to the IMPORT_FROM_AS bytecode, two things would happen:
- Two bytecode operations would have to be performed, per symbol,
rather than one.
- The names imported through `from-import' would be susceptible to
the `global' keyword, which they currently are not. This means
that `from-import' outside of the `*' special case behaves more
like the normal `import' statement, which already follows the
`global' keyword. It also means, however, that the `*' special
case is even more special, compared to the ordinary form of
`from-import'
However, for consistency and for simplicity of implementation, it
is probably best to split off the special case entirely, making a
separate bytecode `IMPORT_ALL' that handles the special case of
`*', and handle all other forms of `from-import' the way the
proposed `IMPORT_FROM_AS' bytecode does.
This dilemma does not apply to the normal `import' statement,
because this is alread split into two opcodes, a `LOAD_MODULE' and a
`STORE_NAME' opcode. Supporting the `import as' syntax is a slight
change to the compiler only.
Copyright
This document has been placed in the Public Domain.
References
[1]
http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
--QKdGvSO+nmPlgiQ/--
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4