Skip to content

Commit

Permalink
reSTify 10 more PEPs (#175)
Browse files Browse the repository at this point in the history 
PEP 221
PEP 229
PEP 240
PEP 277
PEP 286
PEP 295
PEP 297
PEP 306
PEP 341
PEP 666
  • Loading branch information
@Mariatta @berkerpeksag
Mariatta authored and berkerpeksag committed Jan 10, 2017
1 parent a525758 commit b54f01e
Show file tree
Hide file tree
Showing 10 changed files with 813 additions and 712 deletions.
177 changes: 92 additions & 85 deletions pep-0221.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,113 +5,120 @@ Last-Modified: $Date$
Author: [email protected] (Thomas Wouters)
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Aug-2000
Python-Version: 2.0
Post-History:


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.
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 an extension of 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. This can currently be achieved
using the following idiom:

import os
real_os = os
del os

And similarly 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.

A slightly special case exists for importing sub-modules. The
statement

import os.path

stores the module `os' locally as `os', so that the imported
submodule `path' is accessible as `os.path'. As a result,

import os.path as p

stores `os.path', not `os', in `p'. This makes it effectively the
same as

from os import path as p
This PEP proposes an extension of 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. This can currently be achieved
using the following idiom::

import os
real_os = os
del os

Implementation details
And similarly 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.

A slightly special case exists for importing sub-modules. The
statement::

import os.path

This PEP has been accepted, and the suggested code change has been
checked in. The patch can still be found in the SourceForge patch
manager[1]. Currently, a NAME field is used in the grammar rather
than a bare string, to avoid the keyword issue. It introduces a
new bytecode, IMPORT_STAR, which performs the `from module import
*' behaviour, and changes the behaviour of the IMPORT_FROM
bytecode so that it loads the requested name (which is always a
single name) onto the stack, to be subsequently stored by a STORE
opcode. As a result, all names explicitly imported now follow the
`global' directives.

The special case of `from module import *' remains a special case,
in that it cannot accommodate an `as' clause, and that no STORE
opcodes are generated; the objects imported are loaded directly
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
generalize the expression given after the `as' clause. Rather
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
change to accommodate this is minimal, as the patch[2] proves, and
the resulting generalization allows a number of new constructs
that run completely parallel with other Python assignment
constructs. However, this idea has been rejected by Guido, as
`hypergeneralization'.
stores the module ``os`` locally as ``os``, so that the imported
submodule ``path`` is accessible as ``os.path``. As a result::

import os.path as p

stores ``os.path``, not ``os``, in ``p``. This makes it effectively the
same as::

from os import path as p


Implementation details
======================

This PEP has been accepted, and the suggested code change has been
checked in. The patch can still be found in the SourceForge patch
manager [1]_. Currently, a ``NAME`` field is used in the grammar rather
than a bare string, to avoid the keyword issue. It introduces a
new bytecode, ``IMPORT_STAR``, which performs the ``from module import
*`` behaviour, and changes the behaviour of the ``IMPORT_FROM``
bytecode so that it loads the requested name (which is always a
single name) onto the stack, to be subsequently stored by a ``STORE``
opcode. As a result, all names explicitly imported now follow the
``global`` directives.

The special case of ``from module import *`` remains a special case,
in that it cannot accommodate an ``as`` clause, and that no ``STORE``
opcodes are generated; the objects imported are loaded directly
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
generalize the expression given after the ``as`` clause. Rather
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
change to accommodate this is minimal, as the patch [2]_ proves, and
the resulting generalization allows a number of new constructs
that run completely parallel with other Python assignment
constructs. However, this idea has been rejected by Guido, as
"hypergeneralization".


Copyright
=========

This document has been placed in the Public Domain.
This document has been placed in the Public Domain.


References
==========

.. [1] https://hg.python.org/cpython/rev/18385172fac0

[1] http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
.. [2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470

[2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
Loading

0 comments on commit b54f01e

Please sign in to comment.