Re: PEP 420 issue: extend_path
"Eric V. Smith" <[email protected]>
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <[email protected]> |
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)? Or that finders should return a loader or an object (instead of the current PEP 420 behavior of a loader or a string)? I could get behind returning either a loader or another "this could be part of a namespace package" object. But note that in either case we still have to be checking the type of the returned object.