Re: PEP 420 issue: extend_path

On 05/08/2012 08:36 AM, Nick Coghlan wrote:
> No, the idea is to make the two activities (identifying package
> portions and deciding whether or not to continue scanning sys.path)
> *independent*.

I'm all for this.

> Suppose I want to implement a loader where the main path entry is
> actually just a reference to a separately configured path definition
> (e.g. to an application configuration file with an extra set of paths
> to check for Python modules). With a callback API, I can implement
> that directly, since I would be able to just pass the received
> "portion_found" callback down while scanning the subpath with the
> usual sys.path_hooks entries. It doesn't matter if that callback is
> called zero, one or many times - it will still do the right thing.
> 
> Even if the subscan finds several portions before discovering a
> loader, it will *still* do the right thing - the fact we end up
> returning return a loader instead of None would override the fact that
> we previously called "portion_found".
> 
> With the current implementation, there's no option to return
> *multiple* path segments - loaders are restricted to returning at most
> one portion to add to the namespace package.

So have it return a list of strings instead of a single string.

> I think Antoine's right - having to introspect the return type from
> the method call is a major code smell, and I think it's a sign we're
> asking one return value to serve too many different purposes.

I don't disagree with this. But we've got a function that we're asking
to return one of 2 things, as you say. How is this normally handled? I
would not use a callback. I'd return a tuple with the two things:
(loader, list_of_portions). That seems way more straightforward.

Eric.