> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
