Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17705 Modified Files: pep-0000.txt Added Files: pep-0328.txt Log Message: Added PEP 328, Imports: Multi-Line and Absolute/Relative, by Aahz --- NEW FILE: pep-0328.txt --- PEP: 328 Title: Imports: multi-line and absolute/relative Version: $Revision: 1.1 $ Last-Modified: $Date: 2004/01/31 05:14:16 $ Author: Aahz <aahz@pythoncraft.com Status: Draft Type: Standards Track Python-Version: 2.4 Content-Type: text/x-rst Created: 21-Dec-2003 Post-History: Abstract ======== The ``import`` statement has two problems: * Long ``import`` statements can be difficult to write, requiring various contortions to fit Pythonic style guidelines. * Imports can be ambiguous in the face of packages; within a package, it's not clear whether ``import foo`` refers to a module within the package or some module outside the package. For the first problem, it is proposed that parentheses be permitted to enclose multiple names, thus allowing Python's standard mechanisms for multi-line values to apply. For the second problem, it is proposed that all ``import`` statements be absolute by default (more precisely, relative to ``sys.path``) with special syntax for accessing package-relative imports. Rationale for Parentheses ========================= Currently, if you want to import a lot of names from a module or package, you have to choose one of several unpalatable options: * Write a long line with backslash continuations:: from Tkinter import Tk, Frame, Button, Entry, Canvas, Text \ LEFT, DISABLED, NORMAL, RIDGE, END * Write multiple ``import`` statements:: from Tkinter import Tk, Frame, Button, Entry, Canvas, Text from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END (``import *`` is *not* an option ;-) Instead, it should be possible to use Python's standard grouping mechanism (parentheses) to write the ``import`` statement:: from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text LEFT, DISABLED, NORMAL, RIDGE, END) This part of the proposal already has BDFL approval. Rationale for Absolute Imports ============================== In current Python, if you're reading a module located inside a package, it is not clear whether :: import foo refers to a top-level module or to another module inside the package. To resolve the ambiguity, it is proposed that ``foo`` will always be a module or package reachable from ``sys.path``. Because this represents a change in semantics, absolute imports will be optional in Python 2.4 through the use of :: from __future__ import absolute_import This PEP will be updated when it is decided to make absolute imports the default, probably Python 2.5 or 2.6. This part of the proposal already has BDFL approval. Rationale for Relative Imports ============================== With the shift to absolute imports, the question arose whether relative imports should be allowed at all. Several use cases were presented, the most important of which is being able to rearrange the structure of large packages without having to edit sub-packages. In addition, a module inside a package can't easily import itself without relative imports. Guido approved of the idea of relative imports, but there has been a lot of disagreement on the spelling (syntax). There does seem to be agreement that relative imports will require listing specific names to import (that is, ``import foo`` as a bare term will always be an absolute import). Here are the contenders: * One from Guido:: from .foo import and :: from ...foo import These two forms have a couple of different suggested semantics. One semantic is to make each dot represent one level. There have been many complaints about the difficulty of counting dots. Another option is to only allow one level of relative import. That misses a lot of functionality, and people still complained about missing the dot in the one-dot form. The final option is to define an algorithm for finding relative modules and packages; the objection here is "Explicit is better than implicit". (The algorithm proposed is "search up from current package directory until the ultimate package parent gets hit".) * The next set of options is conflated from several posters:: from __pkg__.__pkg__ import and :: from .__parent__.__parent__ import Many people (Guido included) think these look ugly, but they *are* clear and explicit. Overall, more people prefer ``__pkg__`` as the shorter option. * Finally, some people dislike the way you have to change ``import`` to ``from ... import`` when you want to dig inside a package. They suggest completely rewriting the ``import`` syntax:: from MODULE import NAMES as RENAME searching HOW or :: import NAMES as RENAME from MODULE searching HOW [from NAMES] [in WHERE] import ... However, this most likely could not be implemented for Python 2.4 (too big a change), and allowing relative imports is sufficiently critical that we need something now (given that the standard ``import`` will change to absolute import). More than that, this proposed syntax has several open questions: - What is the precise proposed syntax? (Which clauses are optional under which circumstances?) - How strongly does the ``searching`` clause bind? In other words, do you write:: import foo as bar searching XXX, spam as ham searching XXX or:: import foo as bar, spam as ham searching XXX Open Issues =========== The BDFL needs to decide which of the various options for relative imports works best. Additional proposals are still welcome. As usual, Guido prefers reasons to histrionics. References ========== For more background, see the following python-dev threads: - `Re: Christmas Wishlist <http://mail.python.org/pipermail/python-dev/2003-December/040973.html>`__ - `Re: Python-Dev Digest, Vol 5, Issue 57 <http://mail.python.org/pipermail/python-dev/2003-December/041078.html>`__ - `Relative import <http://mail.python.org/pipermail/python-dev/2003-December/041065.html>`__ - `Another Strategy for Relative Import <http://mail.python.org/pipermail/python-dev/2003-December/041418.html>`__ Copyright ========= This document has been placed in the public domain.  .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: Index: pep-0000.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v retrieving revision 1.264 retrieving revision 1.265 diff -C2 -d -r1.264 -r1.265 *** pep-0000.txt 29 Jan 2004 20:17:06 -0000 1.264 --- pep-0000.txt 31 Jan 2004 05:14:15 -0000 1.265 *************** *** 124,127 **** --- 124,128 ---- S 326 A Case for Top and Bottom Values Carlson, Reedy S 327 Decimal Data Type Batista + S 328 Imports: Multi-Line and Absolute/Relative Aahz S 754 IEEE 754 Floating Point Special Values Warnes *************** *** 348,351 **** --- 349,353 ---- S 326 A Case for Top and Bottom Values Carlson, Reedy S 327 Decimal Data Type Batista + S 328 Imports: Multi-Line and Absolute/Relative Aahz SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes