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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4