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

[Geoff Howland]

On 11 Mar 2004 23:29:16 +0100, Dieter Maurer <dieter at handshake.de>
wrote:

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

Agreed.  This transfers the burden of a package maker to know where it
will be installed, which means packages will be more bound to having
to have installers that either cant change their install location
(according at least one sys.path value) or have to store where they
are located in a 3rd party location (registry) or else modify the code
to specific the new path ordering.

Unless I am misunderstanding this at least, it makes it a lot more
difficult to just write a module and have it work.  Currently I almost
never need to mess with the sys.path to get my programs to work.

At worst, I have to do this in the case of running tests on
sub-modules where I execute them from a command line, and they need to
modify the sys.path to get to their brother/parent modules.

It seems this absolute method would mean that you will always have to
have an awareness of where your sub-modules sit, and that seems like
it will lead to a lot more errors when every module that you use is
trying to handle the sys.path and is fighting for top placement for
itself so their sub-modules load properly.

Wont this create a lot more name conflicts when commonly named
sub-modules that are currently always found first will now be
subjugated by another module you imported which has the some commonly
named sub-module and inserted itself into the sys.path?

This seems like a very big change to make default.  Have all the
ramifications of current software that will break and sys.path
position fighitng been evaluated?

Is there something I'm missing that makes this a non-issue?


-Geoff Howland
http://ludumdare.com/