[Python-Dev] New relative import issue

[Guido van Rossum]

On 9/19/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> I haven't really thought it through in detail. It
> just seems as though it would be a lot less confusing
> if you could figure out from static information which
> module will get imported by a given import statement,
> instead of having it depend on the history of run-time
> modifications to sys.path. One such kind of static
> information is the layout of the filesystem.

Eek? If there are two third-party top-level packages A and B, by
different third parties, and A depends on B, how should A find B if
not via sys.path or something that is sufficiently equivalent as to
have the same problems? Surely every site shouldn't be required to
install A and B in the same location (or in the same location relative
to each other).

I sympathize with the problems that exist with the current import
mechanism, really, I do. Google feels the pain every day (alas,
Google's requirements are a bit unusual, so they alone can't provide
much guidance for a solution). But if you combine the various
requirements: zip imports, import hooks of various sorts, different
permissions for the owners of different packages that must cooperate,
versioning issues (Python versions as well as package versions),
forwards compatibility, backwards compatibility, ease of development,
ease of packaging, ease of installation, supporting the conventions of
vastly different platforms, data files mixed in with the source code
(sometimes with their own search path), and probably several other
requirements that I'm forgetting right now, it's just not an easy
problem.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)