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

[Dieter Maurer]

and-google at doxdesk.com (Andrew Clover) writes on 15 Mar 2004 01:52:33 -0800:
> Dieter Maurer <dieter at handshake.de> wrote:
> 
> > This will break lots of code...
> 
> That's why it's a __future__ option.

But you plan, to make it the standard at some point...

> > 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.
> 
> But it's not just used in packages, where the filenames of sibling
> modules are known. There may be scripts in directories with many
> unrelated files, for which relative importing would be highly
> undesirable (or even, in a directory where someone other than the
> owner has write-access, a possible security risk).

Python explicitely adds the directory it finds a script in to the front
of "sys.path". I think it does this because it expects a high
chance that the script *needs* to access modules in this directory.

The behaviour would stay so even when the PEP is implemented,
as all directory listed in "sys.path" are defining what is
considered root level in an "absolute" reference.

> > Relative imports are essential to enhance locality.
> 
> Sure. But we need to separate relative and absolute imports. The status
> quo is inconsistent (sometimes it's relative, sometimes it's not) and
> trips people up. Making the current syntax do an absolute rather than a
> relative import is a good choice because:
> 
>   - in general, absolute imports are used more often;
> 
>   - a proper relative import mechanism requires the ability to 'go up'
>     which can't currently be done, so we'd be inventing new syntax for
>     it anyway.

What about inventing a syntax for absolute imports as well
(and let the behaviour of unadorned imports as it is now).


Dieter