[Python-Dev] __import__ problems

[Brett Cannon]

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.

-Brett