[Import-SIG] PEP 420 issue: extend_path

[Eric V. Smith]

On 05/07/2012 11:00 AM, Antoine Pitrou wrote:
> On Mon, 07 May 2012 09:01:07 -0400
> "Eric V. Smith" <eric at trueblade.com> wrote:
>> 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)?
> 
> Why would it break existing finders? finder_module() would either return
> a loader, or a dedicated object (or None).

If we introduce a new type that all find_module() functions must return
in all cases, it would break existing finders. This object would have a
flag (or some other value) that says either "I returned a loader" or "I
returned a namespace package path". That's how I originally read your
message, but I guess that's not what you're saying.

If we return this new object instead of what PEP 420 currently defines
as a string, then I agree there won't be any impact on existing finders.
Just as there won't be an impact if we define it as a string instead of
some new object.

> Returning a string is completely non-obvious to the caller (who may not
> know about namespace packages or their precise implementation in PEP
> 420).

Well, if you don't know about namespace packages you won't be returning
a string. So I don't see a problem there.

But I agree there's some little part of me that says "why should
namespace packages get to grab string as a return type for
find_module(), when maybe there will be some other use for strings in
the future".

For me, it comes down to future-proofing the API versus the hassle of
defining some new class just to support a use case that may never happen.

Eric.