On Fri, Nov 28, 2008 at 11:07, Mart Somermaa <[EMAIL PROTECTED]> wrote: >> 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 . >
But as people have pointed out, __import__ is not meant to be used directly, and so adding keyword arguments just to make it so it can be used directly is the wrong approach. > 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(). > But you are assuming you need to keep those arguments like global and level, and you really don't if you have the API handle the low-level details as needed. This could really turn into: import_module(name, package) and that gives the machinery everything it needs to do an import, including relative imports. Then all you need to do is: import_module('.baz', __package__) and everything works. > Let me know which of the approaches is desired (if any) and I'll > add tests and update docs. The old-hands on python-dev know this is where I plug my import rewrite vaporware. It will be in 3.1, and as part of it there will be a new API for handling direct imports. Jacob Kaplan-Moss and I have talked about Django's need for this as PyCon so I am very aware of needing this API and it will be addressed in the simplest way possible (heck, the __import__ API might actually become a wrapper around the simpler API in the end). And since nothing can go into 3.0 anyway, there is no need to rush into solving this right now. -Brett _______________________________________________ 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
