> If __import__ was replaced with a version with NON compatible interface,
> "import x.y.z" would break.
But it is not. The proposed __import__(name, submodule=True) has
a compatible interface. All tests pass with
http://bugs.python.org/file12136/issue4438.diff .
As for the imp approach, I've alternatively implemented
imp.import_module() that imports tail modules in
http://bugs.python.org/file12147/imp_import_module.diff
(colour diff in http://dpaste.com/hold/94431/).
IMHO the functionality duplication with __import__ is ugly, but
if it is desired that __import__ does not change (even in
backwards-compatible way), so be it.
The signature and behaviour is as follows:
---
import_module(name, globals, level) -> module
Import the tail module, given dotted module hierarchy in 'name'.
'globals' only determines the package context and is not
modified. 'level' specifies whether to use absolute or relative
imports.
>>> from imp import import_module
>>> import_module('foo.bar.baz')
<module 'foo.bar.baz' from 'foo/bar/baz/__init__.py'>
---
But I'm still +1 for adding 'tail'/'submodule'/'tailmodule'
argument to __import__ instead of providing an almost identical
copy in imp.import_module().
Let me know which of the approaches is desired (if any) and I'll
add tests and update docs.
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