[Import-SIG] PEP 420 issue: extend_path

[Eric V. Smith]

On 05/07/2012 06:53 AM, Antoine Pitrou wrote:
> On Mon, 07 May 2012 10:38:15 +0200
> "Martin v. Löwis" <martin at v.loewis.de> 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.