[Python-Dev] __import__ problems

[Alex Martelli]

On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote:
> ...
>> May I point you to the two leading underscores? The name '__import__'
>> clearly suggests that the function is part of Python's internals. By
>> definition all attributes of the form __*__ are not meant to be used
>> directly.
>
> What about __doc__, __name__ and __slots__, to mention just a few?

Excellent examples of "not meant to be used directly".  __slots__,
like most other special names (though not all) is meant to be *bound*
directly when you need to (which for __slots__ is much more rarely
than for many other special names, mostly those of special methods
that often need to be overridden); but none of these are meant to be
*used* in normal cases -- introspection should normally be done via
provided tools such as the help built-in and standard library modules
such as pydoc and inspect.  It's pretty rare to have to write your own
introspection framework, and the dunder-names are internal machinery
exposed for those rare use cases.


> I believe that __import__() is the recommended way to import a module
> known only at runtime. The docs also don't seem to agree with your
> assertion that __import__ is not to be touched. On the contrary:
>
> "The function is invoked by the import statement. It mainly exists so
> that you can replace it with another function that has a compatible
> interface..."
> http://docs.python.org/library/functions.html

Yes, that documentation predates the current generation of import
hooks which almost remove the need for such trickery.


> Far from saying "Do Not Touch", the docs say "Please, go ahead and
> replace __import__ if needed". If the OP wants "import x.y.z" to load
> module z instead of x, it seems to me that is exactly the problem
> __import__ is designed to allow him to do.

"import x.y.z", the import statement, has well defined semantics
relying on __import__'s interface -- it does load z as well as,
inevitably, its parent y and grandparent x.  If __import__ was
replaced with a version with NON compatible interface, "import x.y.z"
would break.


>> Any suggestion to change the arguments of __import__() are
>> futile. It's not going to happen unless the feature is required by
>> Python's internal import system.
>
> That may very well be true, but I don't know why you're dumping on me.
> It wasn't my suggestion to change __import__. I merely said I could see
> some advantages to it. I spent most of my post telling the OP why I
> thought his arguments were wrong!

And now we're telling you why we think your arguments are also wrong
-- what else do you expect from python-dev after all?


Alex