[Python-Dev] New PEP for import-as (original) (raw)

Thomas Wouters thomas@xs4all.net
Tue, 15 Aug 2000 13:15:42 +0200

--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.0Revision: 1.0 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/--