Re: PEP 420 issue: extend_path
Antoine Pitrou <[email protected]>
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 07 May 2012 09:01:07 -0400 "Eric V. Smith" <[email protected]> wrote: > On 05/07/2012 06:53 AM, Antoine Pitrou wrote: > > On Mon, 07 May 2012 10:38:15 +0200 > > "Martin v. Löwis" <[email protected]> wrote: > >> > >> Interestingly, it appears that pkg_util will break under PEP 420, > >> anyway, as it currently does (in _handle_ns) > >> > >> loader = importer.find_module(packageName) > >> if loader is None: > >> return None > >> ... > >> loader.load_module(packageName); module.__path__ = path > >> > >> Now, if loader suddenly becomes a string, than the load_module > >> call will raise an attribute error (untested). > > > > I think find_module() returning a string is a kludge. It would be > > better IMO if it returned a dedicated object clearly pointing out that > > a namespace package was potentially found (and also allowing to record > > other potential metadata). > > Well the original goal was to allow existing finders to be called > without modification. Are you saying we always return a dedicated object > (thus breaking existing finders)? Why would it break existing finders? finder_module() would either return a loader, or a dedicated object (or None). Returning a string is completely non-obvious to the caller (who may not know about namespace packages or their precise implementation in PEP 420). Regards Antoine.