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

Alex Martelli aleaxit at gmail.com
Fri Nov 28 19:20:01 CET 2008

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

More information about the Python-Dev mailing list