Guido van Rossum wrote: > 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. Ah, good point. I guess it depends on the specific use case... Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
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