Re: PEP 420 issue: extend_path

On 05/09/2012 10:22 PM, Barry Warsaw wrote:
> On May 10, 2012, at 10:55 AM, Nick Coghlan wrote:
> 
>> On Thu, May 10, 2012 at 10:41 AM, Barry Warsaw <[email protected]> wrote:
>>> On May 09, 2012, at 08:19 PM, Eric V. Smith wrote:
>>>
>>>> I modified the PEP to specify these as:
>>>>
>>>> 1. (loader, None)
>>>> 2. (None, <sequence of strings>)
>>>> 3. (None, None)
>>>
>>> wfm.
>>
>> I'd prefer to keep a consistent constraint of "iterable of path
>> entries" for the second value, and allow people to return a non-empty
>> iterable when they're returning a loader (since it will be ignored
>> anyway). See my proposed revision to PathFinder.find_module in my
>> other reply.
> 
> I don't think the implementation should constrain the specification.  Rather,
> what makes the most sense to someone reading the PEP, or the future language
> reference?
> 
> In that respect, I think it's better to define the second item as "ignored" or
> None when not-None is returned as the first element.  Requiring the return of
> an empty sequence when the value is semantically ignored makes no sense.
> 
> There's also a semantic difference between returning None and returning an
> empty sequence as the second element when the first element is None.  In the
> matrix of return states, "(None, ())" means "I found some namespace portions,
> and the number of portions I found is zero" which is clearly nonsensical, and
> subtly different than "I found neither a normal package nor portions of a
> namespace package."
> 
> So I still prefer the current wording of the PEP.

I think trying to explain Nick's version is more complex that what's in
the PEP. Sure, it's a generalization. But you're going to have to
explain that if you discover you don't provide any portions, return a
zero-length iterator.

Both of the find_loader() methods I've written don't have an iterator
around for the paths. It's "yes I have one, and I can compute the path
and from that a list", or "no, I'm not part of a namespace". I think the
case where you'd have a zero-or-more iterator are extremely infrequent.

Eric.