A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2008-November/083772.html below:

[Python-Dev] __import__ problems

[Python-Dev] __import__ problems [Python-Dev] __import__ problemsGuido van Rossum guido at python.org
Sat Nov 29 04:15:18 CET 2008
On Fri, Nov 28, 2008 at 6:56 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Steven D'Aprano wrote:
>> Should this be reported as a documentation bug? Given the new import
>> hooks, would it be fair to say that the main reason for __import__ is
>> to use it to import a module whose name is only known at runtime?
>
> Only known at runtime, and for some reason you want an actual module
> object rather than just the module's global namespace (since you can use
> runpy.run_module() if you only need the latter).
>
> At the very least, the __import__ docs should probably be updated to
> point to run_module() as an alternative approach, so a doc issue is
> probably a good idea.

This sounds wrong to me. run_module() runs the module each time it is
called. __import__ has all the semantics of the import statement (by
definition -- it is almost a tautology :-) in that it first tries to
see if the module is already imported. Pointing to run_module() as an
alternative just perpetuates the misunderstanding (alas fairly common
amongst casual users) about what exactly import does.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

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