Relative Imports, why the hell is it so hard?

Kay Schluehr kay.schluehr at gmx.net
Tue Mar 31 09:50:37 CEST 2009


On 31 Mrz., 04:55, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
> En Mon, 30 Mar 2009 21:15:59 -0300, Aahz <a... at pythoncraft.com> escribió:
>
> > In article <mailman.2591.1237922208.11746.python-l... at python.org>,
> > Gabriel Genellina <gagsl-... at yahoo.com.ar> wrote:
>
> >> I'd recommend the oposite - use relative (intra-package) imports when
> >> possible. Explicit is better than implicit - and starting with 2.7 -when
> >> "absolute" import semantics will be enabled by default- you'll *have* to
> >> use relative imports inside a package, or fail.
>
> > Really?  I thought you would still be able to use absolute imports; you
> > just won't be able to use implied relative imports instead of explicit
> > relative imports.
>
> You're right, I put it wrongly. To make things clear, inside a package
> "foo" accessible thru sys.path, containing a.py and b.py:
>
> site-packages/
>    foo/
>      a.py
>      b.py
>      __init__.py
>
> Currently, the "a" module can import "b" this way:
>
>  from foo import b
> import foo.b
>  from . import b
> import b
>
> When implicit relative imports are disabled ("from __future__ import
> absolute_import", or after 2.7 supposedly) the last one won't find b.py
> anymore.
> (I hope I put it right this time).
>
> --
> Gabriel Genellina

So it even breaks more code which is great ;)

Do you know of any near or far past attempts to re-design the import
system from the ground up? I do not mean a rather faithful and
accessible reconstruction such as Brett Cannons work but a radical re-
design which starts with a domain model and does not end with Loaders,
Importers and Finders which are actually services that pretend to be
objects.

Kay



More information about the Python-list mailing list