Mart Somermaa wrote: > 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 . Your approach complicates the interface. Every implementation of Python and every replacement __import__ would have to implement the additional argument, too. There is simply no need to make the interface more complex when an additional, trivial function does the same job. > > 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. It's not a duplication of functionality. __import__() implements exactly the functionality that is required by Python's import system. Anything else can be implemented on top of it. We simply prefer divide 'n conquer over mingle 'n mix. :) Christian
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