[Import-SIG] PEP 420 issue: extend_path
Eric V. Smith
eric at trueblade.com
Tue May 8 16:07:32 CEST 2012
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)
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.
More information about the Import-SIG