[Python-Dev] Draft: PEP for imports (original) (raw)

Aahz aahz at pythoncraft.com
Mon Jan 19 16:45:29 EST 2004

Here's the draft PEP for imports. I'll wait a few days for comments before sending to the PEPmeister.

PEP: XXX Title: Imports: multi-line and absolute/relative Version: Last-Modified: Author: Aahz <aahz at 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:

For the first problem, it is proposed that parentheses be permitted to surround 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:

:: from Tkinter import Tk, Frame, Button, Entry, Canvas, Text
LEFT, DISABLED, NORMAL, RIDGE, END

:: 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 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.

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:

:: 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".

:: 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.

:: 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).

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:

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:

More information about the Python-Dev mailing list