[Import-SIG] PEP 420 issue: extend_path
barry at python.org
Thu May 10 02:23:11 CEST 2012
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" . 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 on built-in function 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
More information about the Import-SIG