<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">1. I think you absolutely *must* address the option of purely syntactic sugar in the PEP. It will come up on python-dev, so address it now.<br></div><div class="gmail_quote">
<br></div><div class="gmail_quote">    a[b, c=f, e=f:g:h]</div><div class="gmail_quote">    -> a[b, 'c':d, 'e':slice(f, g, h)]</div><div class="gmail_quote"><br></div><div class="gmail_quote">The rationale is readability and being both backwards and forwards compatible - existing __getitem__ designed to abuse slices will continue to work, and __getitem__ designed to work with the new syntax will work by abusing slices in older versions of Python.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Pandas could be cited as an example of an existing library that could potentially benefit. It would be good if there were precise examples of Pandas syntax that would benefit immediately, but I don't know it beyond a cursory glance over the docs. My gut feeling from that is that if the syntax were available Pandas might be able to use it effectively.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">2. I think you're at the point that you need to pick a single option as your preferred option, and everything else needs to be in the alternatives.</div><div class="gmail_quote">
<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">FWIW, I would vote:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">+1 for syntax-sugar only (zero backwards-compatibility concerns). If I were starting from scratch this would not be my preferred option, but I think compatibility is important.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote"><div class="gmail_quote">+0 for a keyword(key, value) parameter object i.e.<br></div><div class="gmail_quote">
<br></div><div class="gmail_quote">a[b, c=d, e=f:g:h]</div><div class="gmail_quote">-> a[b, keyword('c', d), keyword('e', slice(f, g, h))]</div><div class="gmail_quote"><br></div><div class="gmail_quote">
My objection is that either __getitem__ will be more complicated if you want to support earlier versions of Python (abuse slices for earlier versions, use keyword object for current) or imposes an additional burden on the caller in earlier versions (need to create a keyword-equivalent object to call with). If we were starting from scratch this would be one of my preferred options.</div>
<div><br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">-1 to any option that loses the order of the parameters (I'm strongly in favour of bringing order to keyword arguments - let's not take a backwards step here).</div>
<div><br></div><div><div><br></div><div>-0 to any option that doesn't allow arbitrary ordering of positional and keyword arguments i.e. any option where the following is not legal:</div></div><div><br></div><div>a[b, c=d, e]</div>
<div><br></div><div>This is something we can do now (albeit in a fairly verbose way at times) and I think restricting this is likely to remove options for DSLs, etc.</div><div><br></div><div><br></div></div><div class="gmail_quote">
<div class="gmail_quote">-0 for namedtuple (BTW you might want to mention that collections.namedtuple() already has precedent for _X positional parameter names)<br></div></div><div class="gmail_quote"><div class="gmail_quote">
<div><br></div><div>My objection is that it's not possible to determine definitively in __getitem__ if the the call was:</div><div><br></div><div>a[b, c]</div><div><br></div><div>or</div><div><br></div><div>a[_0=b, _1=c]</div>
<div><br></div><div>which might be important in some use cases. The same objection would apply to passing an OrderedDict (but that's got additional compatibility issues).</div><div><br></div><div>Cheers,</div><div><br>
</div></div></div><div class="gmail_quote">Tim Delaney</div></div></div>