[Python-Dev] import problems (original) (raw)

Brett Cannon brett at python.org
Fri Nov 28 21:17:08 CET 2008

On Fri, Nov 28, 2008 at 11:07, Mart Somermaa <mrts at mrts.pri.ee> wrote:

If import was replaced with a version with NON compatible interface, "import x.y.z" would break. But it is not. The proposed import(name, submodule=True) has a compatible interface. All tests pass with http://bugs.python.org/file12136/issue4438.diff .

But as people have pointed out, import is not meant to be used directly, and so adding keyword arguments just to make it so it can be used directly is the wrong approach.

As for the imp approach, I've alternatively implemented imp.importmodule() that imports tail modules in http://bugs.python.org/file12147/impimportmodule.diff (colour diff in http://dpaste.com/hold/94431/).

IMHO the functionality duplication with import is ugly, but if it is desired that import does not change (even in backwards-compatible way), so be it. The signature and behaviour is as follows: --- importmodule(name, globals, level) -> module Import the tail module, given dotted module hierarchy in 'name'. 'globals' only determines the package context and is not modified. 'level' specifies whether to use absolute or relative imports.

from imp import importmodule importmodule('foo.bar.baz') <module 'foo.bar.baz' from 'foo/bar/baz/_init_.py'> --- But I'm still +1 for adding 'tail'/'submodule'/'tailmodule' argument to import instead of providing an almost identical copy in imp.importmodule().

But you are assuming you need to keep those arguments like global and level, and you really don't if you have the API handle the low-level details as needed. This could really turn into:

import_module(name, package)

and that gives the machinery everything it needs to do an import, including relative imports. Then all you need to do is:

import_module('.baz', package)

and everything works.

Let me know which of the approaches is desired (if any) and I'll add tests and update docs.

The old-hands on python-dev know this is where I plug my import rewrite vaporware. It will be in 3.1, and as part of it there will be a new API for handling direct imports. Jacob Kaplan-Moss and I have talked about Django's need for this as PyCon so I am very aware of needing this API and it will be addressed in the simplest way possible (heck, the import API might actually become a wrapper around the simpler API in the end). And since nothing can go into 3.0 anyway, there is no need to rush into solving this right now.

-Brett

More information about the Python-Dev mailing list