PEP 328: Imports: Multi-Line and Absolute/Relative

[Dieter Maurer]

aahz at pythoncraft.com (Aahz) writes on 8 Mar 2004 15:24:56 -0500:
> ...
> 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

Why is this bad?

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

Do do not explain why.

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

This will break lots of code...
I do not like it at all.

A package writer does know which external modules/packages he needs
and can avoid to use the name of one of these modules for his
own modules.

Relative imports are essential to enhance locality.
A package/module should in general not need to know
where it is located inside the package hierarchy to access
its subpackages.

We make extensive use of this locality:
We have myriads of Python packages which are essentially self contained
(apart from references to the standard library). To
avoid pollution of the Python path and name clashes, we
often organize them for concrete projects into folders.
To do this, the packages should not know where they are
located.