Introduction

This PEP describes theimportas proposal for Python 2.0. ThisPEP tracks the status and ownership of this feature. It containsa description of the feature and outlines changes necessary tosupport the feature. The CVS revision history of this filecontains the definitive historical record.

Rationale

This PEP proposes an extension of Python syntax regarding theimport andfrom<module>import statements. These statementsload in a module, and either bind that module to a local name, orbinds objects from that module to a local name. However, it issometimes desirable to bind those objects to a different name, forinstance to avoid name clashes. This can currently be achievedusing the following idiom:

importosreal_os=osdelos

And similarly for thefrom...import statement:

fromosimportfdopen,exit,statos_fdopen=fdopenos_stat=statdelfdopen,stat

The proposed syntax change would add an optionalas clause toboth these statements, as follows:

importosasreal_osfromosimportfdopenasos_fdopen,exit,statasos_stat

Theas name is not intended to be a keyword, and some trickeryhas to be used to convince the CPython parser it isn’t one. Formore advanced parsers/tokenizers, however, this should not be aproblem.

A slightly special case exists for importing sub-modules. Thestatement

importos.path

stores the moduleos locally asos, so that the importedsubmodulepath is accessible asos.path. As a result,

importos.pathasp

storesos.path, notos, inp. This makes it effectively thesame as

fromosimportpathasp

Implementation details

This PEP has been accepted, and the suggested code change has beenchecked in. The patch can still be found in the SourceForge patchmanager[1]. Currently, aNAME field is used in the grammar ratherthan a bare string, to avoid the keyword issue. It introduces anew bytecode,IMPORT_STAR, which performs thefrommoduleimport* behaviour, and changes the behaviour of theIMPORT_FROMbytecode so that it loads the requested name (which is always asingle name) onto the stack, to be subsequently stored by aSTOREopcode. As a result, all names explicitly imported now follow theglobal directives.

The special case offrommoduleimport* remains a special case,in that it cannot accommodate anas clause, and that noSTOREopcodes are generated; the objects imported are loaded directlyinto the local namespace. This also means that names imported inthis fashion are always local, and do not follow theglobaldirective.

An additional change to this syntax has also been suggested, togeneralize the expression given after theas clause. Ratherthan a single name, it could be allowed to be any expression thatyields a valid l-value; anything that can be assigned to. Thechange to accommodate this is minimal, as the patch[2] proves, andthe resulting generalization allows a number of new constructsthat run completely parallel with other Python assignmentconstructs. However, this idea has been rejected by Guido, as“hypergeneralization”.

Copyright

This document has been placed in the Public Domain.

References