Relative Imports, why the hell is it so hard?
Kay Schluehr
kay.schluehr at gmx.net
Tue Mar 31 03:50:37 EDT 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