Relative Imports, why the hell is it so hard?
tjreedy at udel.edu
Tue Mar 31 20:50:14 CEST 2009
Kay Schluehr wrote:
> On 31 Mrz., 18:48, s4g <rafals... at gmail.com> wrote:
> This and similar solutions ( see Istvan Alberts ) point me to a
> fundamental problem of the current import architecture. Suppose you
> really want to run a module as a script without a prior import from a
> module path:
> ...A\B\C> python my_module.py
> then the current working directory C is added to sys.path which means
> that the module finder searches in C but C isn't a known package.
> There is no C package in sys.modules even if the C directory is
> "declared" as a package by placing an __init__.py file in it. Same
> goes of course with B and A.
Nothing is added to sys.modules, except the __main__ module, unless
imported (which so are on startup).
> Although the ceremony has been performed
> basically correct the interpreter god is not pacified and doesn't
But the import 'ceremony' has not been performed.
> But why not? Because it looks up for *living* imported
> packages in the module cache ( in sys.modules ).
> I don't think there is any particular design idea behind it. The
> module cache is just a simple flat dictionary; a no-brainer to
> implement and efficient for look ups.
This all dates to the time before packages and imports from zip files
> But it counteracts a domain model.
What is that?
> All you are left with is those Finders, Loaders and Importers
> in Brett Cannons importlib. Everything remains deeply mysterious and I
> don't wonder that it took long for him to work this out.
And your proposal is?
More information about the Python-list