[Python-Dev] __import__ problems

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.import_module() that imports tail modules in
> http://bugs.python.org/file12147/imp_import_module.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:
> ---
> import_module(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 import_module
>>>> import_module('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.import_module().

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.


More information about the Python-Dev mailing list