Re: PEP 420 issue: extend_path

On May 09, 2012, at 07:46 PM, Eric V. Smith wrote:

>On 5/9/2012 12:14 PM, Barry Warsaw wrote:
>> On May 09, 2012, at 06:19 PM, Nick Coghlan wrote:
>> 
>>> Eric's counter-proposal is to handle the 3 scenarios as:
>>>
>>> 1. (<loader>, <don't care>)
>>> 2. (None, [<path entries>])
>>> 3. (None, [])
>> 
>
>...
>
>> I'd like to relax the formal specification just a bit though, so that the
>> second element is a sequence, not necessarily a concrete list.
>
>I was going to say just use whatever list.extend() is documented to
>accept, but I notice that's "list" [1]. I would assume it can really be
>any iterable. But since len() is called on it (in case 3, above), I
>guess "sequence of strings" is the best description.

The help is a little better:

>>> help([].extend)
Help on built-in function extend:

extend(...)
    L.extend(iterable) -- extend list by appending elements from the iterable

>But if case 3 were changed to (None, None), then I wouldn't need to call
>len(), and it could be any iterable returning strings in case 2. What
>are your thoughts on making case 3 (None, None)? I sort of like it.

+1.  So the formal spec would be that the second item can be "any iterable
returning strings, or None".  I suspect implementations that want to be
maximally Postel would accept any false-ish value instead of exactly None.

>For case 1, I'm currently returning "<don't care>" part as an empty
>string. Should I document it as that, or as really "<don't care>"? I
>don't have an opinion on this.

I think it should be documented as 'ignored' when the first argument is not
None.

Cheers,
-Barry