[Python-Dev] __import__ problems
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
> 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
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"
>> 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?
More information about the Python-Dev