Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reSTify 10 more PEPs #175

Merged
merged 4 commits into from
Jan 10, 2017
Merged

reSTify 10 more PEPs #175

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3c7fd9f
reSTify 10 PEPs
Mariatta Jan 8, 2017
f5f9800
Additional formatting
Mariatta Jan 8, 2017
432ed88
Update broken links in PEP 221 and PEP 277
Mariatta Jan 10, 2017
95c149e
remove extra blank line
Mariatta Jan 10, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
177 changes: 92 additions & 85 deletions pep-0221.txt
View file
Open in desktop
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

``IMPORT_STAR``

\*`` 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

``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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

``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] http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[1] and [2] now returns 404 :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For [1], the actual commit is python/cpython@e6ba0ed (we probably need to use the changeset from hg.python.org since the GitHub link will be broken when we switched to GitHub)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the correct commit in hg.python.org https://hg.python.org/cpython/rev/18385172fac0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated :)


[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