Re: PEP 420 issue: extend_path

On Mon, 07 May 2012 12:00:52 -0400
"Eric V. Smith" <[email protected]> wrote:
> 
> > 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.

I'm talking about calling an arbitrary finder, not one you wrote
yourself.

str is opaque, the str will look like a file path but it's not obvious
that it signals the possibility of a namespace package. Also, if we
later want find_module() to cater for another strange algorithm,
another return type will be needed. Let's be explicit from the start.

> 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.

I say we should future-proof it. This is a public API, we don't want to
paint ourselves in a corner another time.

In any case, do note that returning something else than either a loader
or None already breaks the API, AFAICT. Existing code calling
find_module() will have to be adapted... Which is perhaps worse than
the perceived migration problem in PEP 382.

Regards

Antoine.